On Mon, 2003-02-17 at 18:39, Tom Lane wrote: > > I was thinking of changing reindex_index() to acquire an AccessShareLock > > on the index in question, find its parent rel ID, release the lock, then > > acquire an AccessExclusiveLock on the parent rel, followed by an > > AccessExclusiveLock on the index in question. > > If you release the lock then I think you are opening yourself to worse > troubles than this one, having to do with someone renaming/deleting the > table and/or index out from under you.
Presumably, the renaming/deleting operation acquires an exclusive lock and then holds it until transaction commit, right? If so, then wouldn't we still be okay: the REINDEX would lock the index in access share mode, find the OID of the heap rel, unlock the index, lock the heap rel in access exclusive mode, then try to re-open & lock the index, find that it no longer exists and then elog(ERROR). Whether or not that solution actually works, ISTM there must be *some* method of locking that is free of deadlocks -- saying "oh well, it's not a common case anyway" doesn't strike me as being satisfactory :-\ Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
