Hi, On Wed, Aug 12, 2026 at 2:45 PM Sami Imseih <[email protected]> wrote: > > Thanks for the updates in v3.
Thanks for taking a look at it. > It turns out, to my surprise, that leader_pid can be NULL if the user > querying pg_stat_progress_vacuum does not have proper privileges, either > pg_read_all_stats or membership in the role running the vacuum. Nice catch! > I think for this patch we should drop the reliance on pg_stat_activity > and have pg_stat_get_progress_info() emit leader_pid directly and > unconditionally. The aggregation in the view then works regardless of > the caller's privileges. That's one option. There's another option that I originally proposed upthread, which is to track the leader_pid directly in the progress report. > That leaves a more interesting question in my mind, which is why > pg_stat_activity puts leader_pid behind permissions at all. It should be > treated just like pid. Yes, I looked at the commit (b025f32e0) and the discussion. I think one of the main reasons was to not let unprivileged users take ProcArrayLock and scan over the entire PGPROC array via BackendPidGetProc(). To summarize, we have three options: 1/ Make pg_stat_get_progress_info() report the leader_pid like pg_stat_get_activity() does. 2/ Make pg_stat_get_activity() itself report the leader_pid just like the pid. 3/ Track the leader_pid via a new progress report param (like the v1 did upthread). (1) and (2) will let unprivileged users take ProcArrayLock and scan the entire PGPROC array. (3) although it eats up a new slot in the progress report, gives the leader pid almost for free. I prefer (3) for its simplicity and without any additional risks. Adding Michael Paquier to the thread for any thoughts on this. > There is probably a larger discussion around what should and should not > be permission controlled in pg_stat_activity, and I could not find a > consistent rule. For example, we do not permission control application_name, > which is user controlled free text, yet we do permission control > query_id, which > is not permission controlled elsewhere such as pg_stat_statements. We probably > need a separate thread to clearly lay out the principles for this. The rule here seems simple. The pid or leader_pid by itself is not something that requires permission controls, it is what the users will do to get it that matters. I think this applies to all other params as well. Thoughts? -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
