Re: Problem with ALTER TABLE - occasional "tuple concurrently updated"
От | Robert Haas |
---|---|
Тема | Re: Problem with ALTER TABLE - occasional "tuple concurrently updated" |
Дата | |
Msg-id | AANLkTimnfrO=-C-jZA8NX7Bxp5gcSmgkduGequXPA0T1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Problem with ALTER TABLE - occasional "tuple concurrently updated" (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-bugs |
On Thu, Nov 18, 2010 at 1:35 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Alvaro Herrera's message of jue nov 18 15:31:16 -0300 2010: >> Excerpts from Robert Haas's message of jue nov 18 15:11:37 -0300 2010: >> >> > 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. >> >> What if two of these run at the same time, and the parent doesn't >> have children when they start? =A0They would both try to set >> relhassubclass, no? > > Yep, duplicated the issue that way. I think ATExecAddInherit() and MergeAttributes() need to take ShareUpdateExclusiveLock instead of AccessShareLock to prevent this. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: