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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate