On Wed, Feb 05, 2020 at 02:43:49PM +0900, Fujii Masao wrote: > Hi, > > When I compiled PostgreSQL with -DLWLOCK_STATS and tried to check > the statistics of light-weight locks, I observed that more than one > statistics entries were output *for the same backend process and > the same lwlock*. For example, I got the following four statistics > when I checked how the process with PID 81141 processed ProcArrayLock. > This is strange, and IMO only one statistics should be output for > the same backend process and lwlock. > > $ grep "PID 81141 lwlock ProcArrayLock" > data/log/postgresql-2020-02-05_141842.log > PID 81141 lwlock ProcArrayLock 0x111e87780: shacq 4000 exacq 0 blk 0 > spindelay 0 dequeue self 0 > PID 81141 lwlock ProcArrayLock 0x111e87780: shacq 2 exacq 0 blk 0 spindelay 0 > dequeue self 0 > PID 81141 lwlock ProcArrayLock 0x111e87780: shacq 6001 exacq 1 blk 0 > spindelay 0 dequeue self 0 > PID 81141 lwlock ProcArrayLock 0x111e87780: shacq 5 exacq 1 blk 0 spindelay 0 > dequeue self 0 > > The cause of this issue is that the key variable used for lwlock hash > table was not fully initialized. The key consists of two fields and > they are initialized as follows. But the following 4 bytes allocated > for the alignment was not initialized. So even if the same key was > specified, hash_search(HASH_ENTER) could not find the existing > entry for that key and created new one. > > key.tranche = lock->tranche; > key.instance = lock; > > Attached is the patch fixing this issue by initializing the key > variable with zero. In the patched version, I confirmed that only one > statistics is output for the same process and the same lwlock. > Also this patch would reduce the volume of lwlock statistics > very much. > > This issue was introduced by commit 3761fe3c20. So the patch needs > to be back-patch to v10.
Good catch! The patch looks good to me. Just in case I looked at other users of HASH_BLOBS and AFAICT there's no other cases of key that can contain padding bytes that aren't memset first.
