At Wed, 5 Feb 2020 14:43:49 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in
> 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.
Nice catch. A brielf grepping showed me no another instance of the
same issue. I found some composite hash key struct are used without
intialization but AFAIS they don't have padding before the last
member, or uses strcmp or custom coparison functions. (I don't think
we don't have that in the regular paths, though..)
> This issue was introduced by commit 3761fe3c20. So the patch needs
> to be back-patch to v10.
Agreed.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center