Re: Lock levels for ALTER TABLE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Lock levels for ALTER TABLE
Date: 2013-01-10 05:14:46
Message-ID: 24054.1357794886@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> On Wed, Jan 9, 2013 at 10:27:54PM -0500, Tom Lane wrote:
>>> Something might have slipped through the cracks though.

>> In mvcc.sgml, I see:
>> --> some forms of <command>ALTER TABLE</command>.

> A bit of "git blame" later, the culprit is commit
> 7212c77d0cabcc468fec0b9cd7f2413b64b77050, which I apparently didn't
> recognize as part of what needed to be reverted in
> a195e3c34f1eeb6a607c342121edf48e49067ea9. Will fix.

Actually, I'm not sure the statement is wrong. It's true that the
*target* table of ALTER TABLE is always ex-locked, but there are some
forms such as ALTER ADD INHERIT that take ShareUpdateExclusiveLock on a
parent relation. I'm inclined to leave it alone.

Another issue is that use of ShareUpdateExclusiveLock seems to have
spread into a bunch of newfangled statements that are not mentioned at
all in mvcc.sgml --- look in CommentObject,
ExecAlterExtensionContentsStmt, ExecSecLabelStmt for instance. I
suspect this list is horridly out of date in other ways; I don't think
it even pretends to cover lock usage for non-table objects, for
instance. Perhaps we ought to insert some weasel wording to stop making
it look like the list is intended to be complete, because certainly
nobody is trying very hard to keep it so.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2013-01-10 06:06:40 Re: Enabling Checksums
Previous Message Tom Lane 2013-01-10 04:56:14 Re: Lock levels for ALTER TABLE