Hi, On 2018-11-23 17:41:26 +1300, David Rowley wrote: > Ideally, the locking code would realise we already hold a stronger > lock and skip the lock, but I don't see how that's realistically > possible without probing the hash table for all stronger lock types > first, which would likely damage the performance of locking.
That seems kind of a self-made problem to me. I don't think there's anything really forcing us to have the locallock hashtable contain the lockmode. It'd not be a trivial change, but we could have the locallock entry have enough information to allow us to avoid hitting the shared table if we hold a stronger lock already. The biggest complexity probably would be that we'd need code to downgrade the shared lock we currently hold, when the more heavyweight lock is released. This made me look at LockAcquireExtended() just now. When we acquire a lock that's weaker than one already held, and there's another backend waiting for a conflicting lock, that only works if NOWAIT isn't used. That's because only ProcSleep() gets around to checking whether we already hold a stronger lock, but LockAcquireExtended() bails out for NOWAIT long before that. None of that is documented in LockAcquireExtended(). Isn't that a bit weird? Greetings, Andres Freund
