| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Problem with ALTER TABLE - occasional "tuple concurrently updated" |
| Date: | 2010-11-18 18:31:16 |
| Message-ID: | 1290105030-sup-5154@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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? They would both try to set
relhassubclass, no?
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2010-11-18 18:35:12 | Re: Problem with ALTER TABLE - occasional "tuple concurrently updated" |
| Previous Message | Robert Haas | 2010-11-18 18:11:37 | Re: Problem with ALTER TABLE - occasional "tuple concurrently updated" |