Tom Lane wrote:
> The concern about deadlock applies to the various proposals that involve
> upgrading to a write-prevention lock at some late point in the process.
> That clearly has the potential to deadlock against relatively weak lock
> requests.
After looking at the various lock types, I don't see how this is the
case at all (which may mean that I'm more confused than ever. But
please read on). It seems to me that only ops that promote to
AccessExclusiveLock can deadlock against at least some of the proposed
REINDEX implementations.
REINDEX would have to initially grab AccessShareLock, of course, but
AccessExclusiveLock is the only lock type that blocks against it, so
in the case of lock promotion the only operations that would cause
REINDEX to really deadlock (as opposed to simply blocking) are
operations on the entire table (ALTER TABLE, DROP TABLE, etc.).
None of the common operations block against an AccessShareLock, and
the order of acquisition against objects (table vs index) is already
enforced, so where's the deadlock potential?
REINDEX would, I expect, promote its lock to ShareLock when it's time
for it to block writers. That would block against quite a number of
operations, of course, but that's not a problem in and of itself,
because it need only wait until the operations in question are
finished. The lock won't be granted until those other operations are
finished, and nothing aside from table-level ops will block against
the REINDEX until that lock is granted. A true deadlock won't happen
against common operations unless REINDEX promotes its lock again to
something stronger than ShareLock, and that's easy to avoid: just have
REINDEX promote directly from AccessShareLock to the strongest lock it
will ever need.
--
Kevin Brown kevin@sysexperts.com