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
signature.asc
Description: PGP signature
