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.
