| From: | solai v <solai(dot)cdac(at)gmail(dot)com> |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add a permission check to pg_stat_get_backend_subxact() |
| Date: | 2026-09-25 06:23:22 |
| Message-ID: | CAF0whud_ankyWdQb476mbVCVNnWEm6goUKHP+WA0rzpvD4bjYA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi all,
On Thu, Sep 24, 2026 at 12:03 PM shihao zhong <zhong950419(at)gmail(dot)com> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Antonin Houska | 2026-09-25 06:24:15 | Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten |
| Previous Message | vignesh C | 2026-09-25 06:15:20 | Re: Up to 50x degradation in dblink performance when receiving notice traffic 19 vs 18 |