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
