Re: Problem with ALTER TABLE - occasional "tuple concurrently updated"
От | Robert Haas |
---|---|
Тема | Re: Problem with ALTER TABLE - occasional "tuple concurrently updated" |
Дата | |
Msg-id | AANLkTimLfhgsZbUrqk1Rd+uJ9A5LAvUt11wAdUz-9fEQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Problem with ALTER TABLE - occasional "tuple concurrently updated" (Jon Nelson <jnelson+pgsql@jamponi.net>) |
Ответы |
Re: Problem with ALTER TABLE - occasional "tuple concurrently updated"
|
Список | pgsql-bugs |
On Thu, Nov 18, 2010 at 10:28 AM, Jon Nelson <jnelson+pgsql@jamponi.net> wr= ote: > On Wed, Nov 17, 2010 at 8:57 PM, Robert Haas <robertmhaas@gmail.com> wrot= e: >> On Tue, Nov 16, 2010 at 10:48 AM, Jon Nelson <jnelson+pgsql@jamponi.net>= wrote: >>> I have a process which runs in parallel creating tables which, as the >>> /final/ step in the import, gets SQL much like the following applied: >>> >>> ALTER TABLE foo INHERIT bar; >>> >>> Periodically, I get this error: =A0tuple concurrently updated >> >> The ALTER TABLE generates that error? =A0Is it running concurrently with >> any other DML? =A0What version of PostgreSQL is this? > > Yes, sometimes yes, and 8.4.5. Any chance you can isolate a reproducible test case? Maybe a series of steps to be run in two psql sessions? Or any idea what DDL might be running against the parent at the same time? In the current master branch, it appears that "ALTER TABLE c INHERIT p" takes a ShareUpdateExclusiveLock on the child, which seems sufficient, and an AccessShareLock on the parent, which seems like it might not be; though I'm having a hard time figuring out exactly when it wouldn't be, especially since in 8.4 I'm fairly sure any ALTER TABLE command takes an AccessExclusiveLock. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: