Re: A bug in LWLOCK_STATS

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: masao(dot)fujii(at)oss(dot)nttdata(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: A bug in LWLOCK_STATS
Date: 2020-02-05 08:25:18
Message-ID: 20200205.172518.2289455448283067621.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 5 Feb 2020 14:43:49 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-02-05 08:30:38 Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side
Previous Message Amit Kapila 2020-02-05 08:19:20 Re: Documentation patch for ALTER SUBSCRIPTION