Noah, Providing my thoughts on the 'mundane' question first.
On Tue, May 24, 2011 at 1:40 PM, Noah Misch <n...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
