On Wed, Sep 23, 2026 at 07:23:01AM +0000, Bertrand Drouvot wrote:
> typedef struct PgStat_Backend
> {
> + int pid; /* PID of the backend
> owning these stats */
> TimestampTz stat_reset_timestamp;
>
> 0002 explicitly says that it is not intended for backpatching, but what about
> 0001? If it is backpatched to v18, adding pid here changes the offsets of all
> the existing fields.One thing that itches me quite a bit about adding a cross-check of the PID in the set of checks is that it also changes the behavior of stats_fetch_consistency when set to "cache" or "snapshot", by forcibly discarding the stats numbers previously fetched when requesting stats for a PID that matches with a previous procnumber slot, so it is just switching from one behavior to another. In terms of implementation simplicity, I see more merit with the existing logic where we don't add a PID tracking because it's well, simpler! And the problem with these numbers only becomes a problem if we deal with a connection turnover that it impacts the numbers obtained. The main use case of backend stats is for benchmarking and get numbers with longer-running connections, so as a whole I think that we are making a big issue of something that is not really one in practice. Note that there is a parallel with replication slot stats, which are indexed not by name but with an integer number. A backend could grab in a snapshot data from slot 1, while concurrent activity has the idea to drop and recreate a slot. The snapshot would still refer to the data of the previous slot. If we aim at improving this kind of use cases with stats snapshots, and I am not sure that it's really worth bothering, this should work across all the stats kinds, not be plugged multiple times across the board. The role ID case is different: we want consistency to check for the permissions. -- Michael
signature.asc
Description: PGP signature
