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
- pgstat_reuse_fix_a.txt (text/plain)
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
-
Fix race conditions with drop of reused pgstats entries
- 154c5b42a3d8 15.10 landed
- afa20845dd13 16.6 landed
- 1d6a03ea4146 17.2 landed
- 818119afccd3 18.0 landed
-
Prevent inconsistent use of stats entry for replication slots
- bfc44da24789 15.8 landed
- f2c922ff2fed 16.4 landed
- cd312adc561a 17.0 landed
-
pgstat: store statistics in shared memory.
- 5891c7a8ed8f 15.0 cited