Re: Lock levels for ALTER TABLE

I wrote:
> Bruce Momjian <bruce@momjian.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