Re: pgstat: don't assert on dropped entries when writing stats file

On Fri, Oct 16, 2026 at 10:53:01AM -0500, Sami Imseih wrote:
> I ran into a small pgstat assertion failure while looking at this code
> recently.

I've been wondering for some time if this could be reached with a set
of deterministic steps, but never got down to track if there were such
a sequence.

> The old comment made this sound like something that should not happen, or at
> least like some cleanup went sideways. But this case can happen without
> anything going wrong.
>
> We could probably fix this in the reinitialization path instead, but
> that feels like a lot of complexity for a state we can already tolerate.
> pgstat_write_statsfile() already skips dropped entries before serializing
> them, so the patch just removes the assertion and updates the comment to
> match that.

Hmm. This assertion has proved to be useful in the past, to be able
to track stale entry references in the hash table where we don't
expect them, pointing at some real bugs. See for example
da99fedf8c17.

On top of the generation check, how about doing something in
pgstat_release_entry_ref() if we have a dropped entry with a refcount
of 0 and the generation does not match? Hence, I'd suggest that we
should free the entry more aggressively, perhaps.. I have not tested
this idea, but just getting rid of this assertion does not feel like
the right move to me as it means that we leave in the shared hashtable
entries that should be gone, and that these entries will never be gone
until the same key is reused. For the replication slots or an
index-based logic, the turnover should be quick, but that may not be
the case for all stats kinds.
--
Michael