> On Tue, Oct 21, 2025 at 01:26:30PM -0500, Sami Imseih wrote:
> > Hmm, since the pgstat.stat file is managed by core and not by the
> > extension, I think this should be handled semi-automatically by
> > pgstats. Even with the checks you mention above, validating that we
> > are indeed loading the same kind will never be totally foolproof. I
> > think we can validate kinds better by adding some MAGIC NUMBER that is
> > set by the extension during registration and tracked in pgstats.stat.
> > If the kind ID
> > and MAGIC NUMBER (for example, FORMAT ID) match, then we have more of
> > a guarantee that this is the same extension. Also, this is probably a
> > good idea to support extension upgrades.
>
> Probably. Still, it does not feel like something we need to push
> strongly in a given direction, because we may pay in flexibility
> compared to what's on HEAD.
>
> With a single kind ID forcing how large a fixed-sized entry or one
> variable-sized entry should be based on what kind of data is loaded,
> versioning something based on a single kind is impossible (or the same
> size is used, leading to different contents translated). Of course,
> one could use multiple kind IDs if they want to enforce different
> stats versions in a single major version of the backend. To me, this
> property comes down that the version of the pgstats file cannot change
> in a single major version, implying that the same rule is also pushed
> to the custom kinds: if you begin to use a kind ID in a given major
> version, do not change the stats format, limitting new changes to a
> new major version. Or an upgrade format path to use is something an
> extension needs to handle on its own. I'd bet that stats upgrade
> requirements for the same major version are not going to be that
> common, the future may tell a different story depending on the use
> cases that pop.
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.
But also, stats themselves are for the most part are consumed
in a way that can tolerate stats being reset, because most of the
time a user is taking deltas of stats between snapshots.
The autovacuum case is special, and the work that Bertrand is
doing will be beneficial to ensure that a/v has the correct stats
after crash recovery.
--
Sami
