We've got various facilities now for looking at LWLock waits, but I'd
like to have more information about the *reasons* for lock waits.
I know its possible to get backtraces in Dtrace at various tracepoints
but that can be fairly hard to interpret.
I'm thinking of adding an extra parameter onto every call to
LockBuffer() and LWLockAcquire() to explain the reason for the lock
request.
Then when we analyze lock waits we can apportion the lock wait reason
correctly and determine not just where the waits are happening, but
*why* the waits are happening. Activity Based Costing the beanies call
it.
This will be especially helpful with transitory events that might (or
might not) occur fairly frequently, yet the point of contention moves
around within the server. There's a few hotspot reasons that move
around, plus I'm certain there's one or two we have no idea about.
This won't help much for highly contended locks where a lock queue of
100 might have 99 fast lock holders and 1 slow one. But it will help for
the transitory locking where a lock is frequently not held, yet we want
to explain what was happening when the lock *was* held.
Reason would be an enum value and reporting would probably be covered by
LWLOCK_STATS.
-- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
