| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> |
| Subject: | Re: Report index currently being vacuumed in pg_stat_progress_vacuum |
| Date: | 2026-08-14 03:33:03 |
| Message-ID: | an6Mbz9RUlAxKslz@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 13, 2026 at 07:47:06PM -0500, Sami Imseih wrote:
> 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?
That's debatable perhaps, but the leader PID is in the same kind of
category as the wait events: no information derived from a PGPROC
entry should be viewable except for a role with pg_read_all_stats
privileges or if a role is a member of the role whose information is
queried.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tender Wang | 2026-08-14 03:38:56 | Re: Performance regression caused by SubLink pull-up |
| Previous Message | Srinath Reddy Sadipiralla | 2026-08-14 03:18:47 | Re: Credits For v19 |