Hi all, On Thu, Sep 24, 2026 at 12:03 PM shihao zhong <[email protected]> wrote: > > Hi Michael, > > > 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! > > OK, v10 drops the PID from the stats entry. v10-0001 is the permission > patch, and the entry stores only the role of the backend. That is enough > for the snapshot case upthread. The old entry keeps the role of the old > backend, so u1 gets nothing from it. I checked it with the same script. > > > The role ID case is different: we want consistency to check for the > > permissions. > > v10-0002 is optional and follows that idea for Bertrand's point on > pg_stat_get_backend_subxact(). The role is checked from the copied status > entry, but the subxact counters are read from PGPROC in a second step. > The PID check makes sure both come from the same backend. Your call. > >
Thank you for the updated patches. I tested the patch and the regression suite completed successfully with all 239 tests passing. I also performed targeted testing of the per-backend statistics permission checks. The results were as expected: 1. The role owning the backend could access the per-backend statistics. 2. An unrelated role could not access the statistics. 3. A role with pg_read_all_stats privileges could access them again. I reviewed the changes for pg_stat_get_backend_subxact(), pg_stat_get_backend_io(), pg_stat_get_backend_wal(), and pg_stat_get_backend_lock(), and verified that the permission checks are applied consistently. I also checked the PID validation in pgstat_fetch_stat_backend_by_pid(). The requested PID is compared with st_procpid before the backend statistics entry is fetched, which addresses the PID/ProcNumber consistency concern discussed in the thread. Overall, I did not find any additional issues during my testing and review. The patch looks relevant to the reported issue from my testing. Regards, Solai
