Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Floris Van Nee <florisvannee@optiver.com>
Cc: Andres Freund <andres@anarazel.de>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "exclusion@gmail.com" <exclusion@gmail.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2024-06-05T23:51:10Z
Lists: pgsql-bugs 
On Wed, Jun 05, 2024 at 10:24:43AM +0000, Floris Van Nee wrote:
> I noticed it but wasn't sure if it was necessary here due to the exceptional case here.
> It raises ereport error right after and can only reach this if the entry was created
> In the call to pgstat_prep_pending_entry before it, so it seems unlikely another
> backend holds a ref to it. I might be wrong though.

It does not prevent addressing the original issue, so pushed down to
15 after running concurrent tests for a few extra hours.

>> Attached is an updated patch with refined comments at the top of ?
>> pgstat_drop_entry(), to be applied to 15~.
> 
> Thanks for testing the patch. Updated patch looks good to me.

I'll try to look at this one separately.
--
Michael

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.