Re: Report index currently being vacuumed in pg_stat_progress_vacuum

Hi,

On Wed, Aug 12, 2026 at 2:45 PM Sami Imseih <samimseih(at)gmail(dot)com> 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