On Mon, Sep 21, 2026 at 09:58:27AM +0000, Bertrand Drouvot wrote: > One thing I noticed while looking at this is that with > stats_fetch_consistency = snapshot, > pgstat_fetch_stat_backend_by_pid() could validate the PID and user from one > backend > while returning cumulative statistics cached for an older backend that used > the > same ProcNumber.
I was wondering about the validity of this argument regarding a possible split of 0001 and 0002. And this points to the fact that 0001 is simply unsafe: we should not do a HAS_PGSTAT_PERMISSIONS() based on the user ID retrieved from a beentry as it may refer to a role different than the one associated to the stats data depending on the level of stats consistency. I don't see a way through here except by storing more information into the stats entries themselves to use in the checks. Another option than the PID would be to store the user ID in the stats entry and reuse it for the HAS_PGSTAT_PERMISSIONS() check? If we do that, a snapshot of the data would still be able to work even if the proc slot is reused due to a slot being recycled, and that could be arguably more useful than the PID (a session willing a snapshot of the data would still be able to refer to it based on a past point)? I'd slightly prefer storing a user ID, I think, because it means that the ACL check is done only based on the stats data, and there would be no cross-dependency between the data in the beentry and the stats data. Perhaps you have a different view or more ideas? -- Michael
signature.asc
Description: PGP signature
