| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | shihao zhong <zhong950419(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-24 01:01:02 |
| Message-ID: | arR2TkF9msIowJjh@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Xuneng Zhou | 2026-09-24 01:03:24 | Re: pg_walinspect: fix LSN validation messages and empty range handling |
| Previous Message | shihao zhong | 2026-09-24 00:52:23 | Re: REPACK (CONCURRENTLY) loses missing values of columns added without a rewrite |