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