Re: A bug in LWLOCK_STATS - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: A bug in LWLOCK_STATS
Date
Msg-id 20200205.172518.2289455448283067621.horikyota.ntt@gmail.com
Whole thread Raw
In response to A bug in LWLOCK_STATS  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Documentation patch for ALTER SUBSCRIPTION
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side