Noah,
Providing my thoughts on the 'mundane' question first.
On Tue, May 24, 2011 at 1:40 PM, Noah Misch <noah@leadboat.com> wrote:
>
> I also had a more mundane design question in the second paragraph of [2]. It
> can probably wait for the review of the next version of the patch. However,
> given that it affects a large percentage of the patch, I'd appreciate any
> early feedback on it.
Here's the relevant part of the original post:
> ATPostAlterTypeCleanup has this comment:
> /*
> * Re-parse the index and constraint definitions, and attach them to the
> * appropriate work queue entries. We do this before dropping because in
> * the case of a FOREIGN KEY constraint, we might not yet have exclusive
> * lock on the table the constraint is attached to, and we need to get
> * that before dropping. It's safe because the parser won't actually look
> * at the catalogs to detect the existing entry.
> */
> Is the second sentence true? I don't think so, so I deleted it for now. Here
> is the sequence of lock requests against the table possessing the FOREIGN KEY
> constraint when we alter the parent/upstream column:
>
> transformAlterTableStmt - ShareRowExclusiveLock
> ATPostAlterTypeParse - lockmode of original ALTER TABLE
> RemoveTriggerById() for update trigger - ShareRowExclusiveLock
> RemoveTriggerById() for insert trigger - ShareRowExclusiveLock
> RemoveConstraintById() - AccessExclusiveLock
> CreateTrigger() for insert trigger - ShareRowExclusiveLock
> CreateTrigger() for update trigger - ShareRowExclusiveLock
> RI_Initial_Check() - AccessShareLock (3x)
I think the statement in the second sentence of the comment is true.
ATPostAlterTypeParse is called only from ATPostAlterTypeCleanup. It has to
grab the lock on the table the constraint is attached to before dropping the
constraint. What it does is it opens that relation with the same lock that is
grabbed for AT_AlterColumnType subtype, i.e. AccessExclusiveLock. I think
there is no preceding place in AlterTable chain, that grabs stronger lock on
this relation. ShareRowExclusiveLock is taken in transformAlterTableStmt (1st
function in your sequence), but this function is ultimately called from
ATPostAlterTypeParse, just before the latter grabs the AccessExclusiveLock, so
ultimately at the point where this comment is located no locks are taken for
the table with a FOREIGN KEY constraint.
Alexey.
