Re: Missing LWLock protection in pgstat_reset_replslot()

Hi,

On Wed, Dec 04, 2024 at 03:45:13AM +0300, Anton A. Melnikov wrote:
> Hi!
> 
> b36fbd9f8d message says that inconsistency may still be possible because
> statistics are not completely consistent for a single scan of
> pg_stat_replication_slots under concurrent replication slot drop or
> creation activity.
> 
> Seems there is a reproduction of such a case via isolation test.
> Please see the repslot_stat.spec attached.

Thanks for the report!

While I agree that your test case does produce a failed assertion, I don't
think it's linked to b36fbd9f8d (which focused on retrieving consistent stats).

As far your test case, it produces:

TRAP: failed Assert("!ps->dropped"), File: "pgstat.c", Line: 1400, PID: 189292

I did some test and from what I can see:

This is due to the fact that the "dropped" entry is "still in pgStatLocal.shared_hash".

Indeed, during the shutdown, Session 1 is going through:

pgstat_report_disconnect()->…->pgstat_get_entry_ref()->pgstat_gc_entry_refs()->
pgstat_release_entry_ref()-> “Shared stats entry has been reinitialized, so do not drop”

So it's not dropping the entry because It's going in the "Shared stats entry has been reinitialized"
case in pgstat_release_entry_ref().

It's doing so because the previous test:

"
if (pg_atomic_read_u32(&entry_ref->shared_entry->generation) ==
    entry_ref->generation)
"

is false (entry_ref->shared_entry->generation is 1 while entry_ref->generation
is 0).

I need to think more about it but it seems to me that those values make sense,
so maybe we should drop the entry for this particular case (shmem_exit()).

Thoughts?

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com