The intention of this feature is to give the ability to slip into a normal workload for non-urgent maintenance work. In essence, instead of lock waiters being in a Queue, DEFERRABLE causes the current lock statement to always be last. It was discussed at last years pgCon as useful for replication tools adding/removing triggers. I've also seen more than one plpgsql loop using subtransactions and LOCK TABLE .. NOWAIT to achieve a similar effect. IMO, it's much cleaner built in.
If a lock is successfully obtained on one table, but not on all tables, it releases that lock and will retry to get them as a group in the future. Since inheritance acts as a group of tables (top + recursive cascade to children), this implementation is necessary even if only a single table is specified in the command.
Like various CONCURRENT commands, it waits on a set of transactions which were found to be blocking it. This puts it into the "waiting" state and allows isolation testing to work as expected. I started with a simple loop with a timer (and a GUC) but it didn't feel right without pg_stat_activity showing the waiting state. statement_timeout is suggested for a time restriction.
Possibly Ugly stuff:
SetLocktagRelationOid() no longer static inline. Better option? My C foo isn't all that it should be. Lock Table allows locking shared tables so I can't just assume MyDatabaseId is sufficient for the lock tag.
Return value InvalidOid in RangeVarGetRelidExtended() can now appear in 2 different situations; relation missing if missing_ok enabled and relation unlockable if LockWaitPolicy LockWaitNonBlock. No callers currently use both of these options at this time.
LockTableRecurse() returns the OID of the relation it could not lock in order to wait on the processes holding those locks. It also keeps a list of everything it did lock so they can be unlocked if necessary.
I'll add it to the open November commitfest.
regards,
Rod Taylor
