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.
--
Michael
