On Mon, Sep 21, 2026 at 07:54:04PM -0400, shihao zhong wrote: > v5-0002 fixes it by making the PID part of the object ID of the backend > stats entries. The entry of an older backend is then never found with > the PID of a newer one, and nothing needs to be checked after the fetch. > Entries are still dropped at exit, so the number of live entries is still > bounded by the number of proc numbers.
+ * Object ID of the stats entry of a backend. The PID is part of the key, so + * that an entry cached for an older backend that used the same proc number, + * for example in a stats snapshot, is never mistaken for the entry of the + * backend currently using this proc number. + */ +#define PGSTAT_BACKEND_OBJID(pid, procnum) \ + ((((uint64) (uint32) (pid)) << 32) | (uint32) (procnum)) This breaks the fundamental law of the backend stats and makes the whole more brittle. Having *only* the procnum in the key naturally caps the maximum amount of shared memory used by this stats kind because they would be recycled when connecting a new backend. You are removing this cap, so your patch means a lot of potential bloat on a live server in the shared hash table used by pgstats, the more bloat the more connection turnover. One approach that may be saner is to store a trace of the PID in PgStat_Backend when a new backend connects, then compare it back with the existing PGPROC entry, then decide what to show based on the state of both. That should be much cheaper, and much lower in shared memory footprint than what you are suggesting. -- Michael
signature.asc
Description: PGP signature
