On Tue, Mar 22, 2022 at 1:43 PM Andres Freund <and...@anarazel.de> wrote: > When LockAcquireExtended(dontWait=false) acquires a lock where we already hold > stronger lock and somebody else is also waiting for that lock, it goes through > a fairly circuitous path to acquire the lock: > > A conflicting lock is detected: if (lockMethodTable->conflictTab[lockmode] & > lock->waitMask) > LockAcquireExtended() -> WaitOnLock() -> ProcSleep() > ProcSleep() follows this special path: > * Special case: if I find I should go in front of some waiter, check > to > * see if I conflict with already-held locks or the requests before > that > * waiter. If not, then just grant myself the requested lock > immediately. > and grants the lock.
I think this happens because lock.c is trying to imagine a world in which we don't know anything a priori about which locks are stronger or weaker than others and everything is deduced from the conflict matrix. I think at some point in time someone believed that we might use different conflict matrixes for different lock types. With an arbitrary conflict matrix, "stronger" and "weaker" aren't even necessarily well-defined ideas: A could conflict with B, B with C, and C with A, or something crazy like that. It seems rather unlikely to me that we'd ever do such a thing at this point. In fact, there are a lot of things in lock.c that we'd probably do differently if we were doing that work over. -- Robert Haas EDB: http://www.enterprisedb.com
