On Wed, Oct 22, 2025 at 03:57:15PM -0500, Sami Imseih wrote:
> OK, fair enough. I don't have enough compelling use-cases to push
> back harder on this. Initially, my focus was on the fact that unlike
> built-in stats, custom stats may not have a registered kind and
> disposing of all the stats in that case did not seem like the appropriate
> behavior, or least too strict of a behavior.
Two things that may be useful here, as long as I have this problem in
mind..
First, could it could be useful to have an in-core function able to
remove from shared memory all the entries related to a specific stats
kind, taking in input a kind ID? At least for variable-sized data in
the shared hashtable, that could become useful.
A second potential improvement would be to bypass the write of a
fixed-numbered stats kind if we detect that nothing needs to be
written because there is no data, after a reset or if we detect it as
full of zeroes. The format of the file with PGSTAT_FILE_ENTRY_FIXED
makes this flexibility possible, and we could extend the snapshot_cb
and pgstat_build_snapshot_fixed() so as they return a boolean flag to
let the upper layer decide if some data should be written or not.
If you combine the first system function with resets and the tweak for
the fixed-numbered stats, then one could reset/remove the stats, drop
a custom kind from s_p_l, and still preserve the rest of the stats.
That's more steps than doing all that automatically, but that feels
also a bit more bullet-proof if one wants to "upgrade" a stats kind by
reusing the same kind ID across two restarts.
--
Michael
