Re: Report index currently being vacuumed in pg_stat_progress_vacuum

>
> Hi,

3/ Track the leader_pid via a new progress report param (like the v1
> did upthread).

Yes, this seems like the best way. Have the workers report their leader.

> (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?

I agree. At least the leader_pid should not be permission controlled and we
should
be able to perform the aggregation as we do in v3- at the sql level. Other
fields like
relid, phase, etc. sit behind permission controls and should remain that
way. If there
is different opinion for those fields, that is a separate discussion.

WDYT?

--
Sami