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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend