Re: Add a permission check to pg_stat_get_backend_subxact()

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: shihao zhong <zhong950419(at)gmail(dot)com>
Cc: 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-22 00:12:30
Message-ID: arHH7ihI4EqUzTQ-@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-09-22 00:12:39 Re: aio: worker: Free SMGR objects when idle
Previous Message Bharath Rupireddy 2026-09-22 00:07:21 Re: Support for 8-byte TOAST values, round two