Today, here is some highlight about a small feature that will available in Postgres 9.6, useful for application and monitoring purposes:
commit: aa65de042f5828968f2f6cd65f45c543a40cc3e6
author: Robert Haas <rhaas@postgresql.org>
date: Fri, 11 Sep 2015 14:01:39 -0400
When trace_lwlocks is used, identify individual lwlocks by name.
Naming the individual lwlocks seems like something that may be useful
for other types of debugging, monitoring, or instrumentation output,
but this commit just implements it for the specific case of
trace_lwlocks.
Patch by me, reviewed by Amit Kapila and Kyotaro Horiguchi
A light-weight lock is a type of lock used by a PostgreSQL instance taken for a short duration, in the order of a fraction of microseconds or a couple of instructions, primarily to avoid the manipulation of the same shared memory areas by multiple backends at the same time.
Monitoring those locks is possible if the code has been compiled with the compilation flag LOCK_DEBUG, and if the configuration parameter trace_lwlocks is set to on in postgresql.conf. Up to 9.5, logging information about those locks resulted in an output similar to that, here the example being a lock acquired during the generation of a transaction XID whose creation has been enforced with txid_current():
LOG: 79507: LWLockAcquire(main 3): excl 0 shared 0 haswaiters 0 waiters 0 rOK 1
LOG: LWLockAcquire(main 3): immediately acquired lock
LOG: 79507: LWLockRelease(main 3): excl 0 shared 0 haswaiters 0 waiters 0 rOK 1
This information is useful, still user needs to have a look at the lock table, located in lwlock.h, to understand that in this case the light-weight lock referenced is XidGenLock.
Thanks to the commit above, things get more verbose for the user though, the logs getting generated as follows for the same code path in the Postgres backend:
LOG: 84588: LWLockAcquire(XidGenLock): excl 0 shared 0 haswaiters 0 waiters 0 rOK 1
LOG: LWLockAcquire(XidGenLock): immediately acquired lock
LOG: 84588: LWLockRelease(XidGenLock): excl 0 shared 0 haswaiters 0 waiters 0 rOK 1
This approach presents the advantage to not have to go through the existing lock table in lwlock.h to get the reference name of a lock in lwlock.h, which is replaced by a header file generated by a perl script used at compilation-time.