Re: BUG #17947: Combination of replslots pgstat issues causes error/assertion failure

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-06-02T21:34:18Z
Lists: pgsql-bugs

Attachments

At Thu, 01 Jun 2023 08:42:45 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> The attached ad-hoc patch appears to be working somehow for this
> specific scenario. (It can contain any defects including possible
> shared entry leaks.) We need to find a better approach to prevent the
> reuse of an already-reinited entry.  I believe it can be fixed by
> adding a reuse count to both the cached entry and shared entry, then
> we could compare these numbers to verify the cached entry. However, I
> can't think of a solution that wouldn't require additional struct
> members for now.  Thus I'm not sure how to fix this for older versions
> without them..

Here's the alpha version of that. This doesn't modify on-disk data
format and I don't think anyone outside the core relies on the
internal data structure. So it would be back-patcheable.

This problem brings another concern regarding how concurrent reusing
and refetching existing entries work safely.  At least, it is not
great to have to check two variables. It would be better combining
"dropped" with the reuse-count. In other words, checking if an entry
is in the dropped state by examining the reuse-count value.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Commits

  1. Fix race conditions with drop of reused pgstats entries

  2. Prevent inconsistent use of stats entry for replication slots

  3. pgstat: store statistics in shared memory.