Re: docs: mention "pg_read_all_stats" in "track_activities" description - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: docs: mention "pg_read_all_stats" in "track_activities" description
Date
Msg-id YorM9Kv4bFVBoCsI@paquier.xyz
Whole thread Raw
In response to Re: docs: mention "pg_read_all_stats" in "track_activities" description  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: docs: mention "pg_read_all_stats" in "track_activities" description  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
On Sun, May 22, 2022 at 01:26:08PM -0700, Nathan Bossart wrote:
> Yeah, this crossed my mind.  I thought that "superusers, roles with
> privileges of the pg_read_all_stats_role, roles with privileges of the user
> owning the session being reported on, and the user owning the session being
> reported on" might be too long-winded and redundant.  But I see your point
> that it might be a bit confusing.  Perhaps it could be trimmed down to
> something like this:
>
>     ... superusers, roles with privileges of the pg_read_all_stats role,
>     and roles with privileges of the user owning the session being reported
>     on (including the session owner).

Yeah, that sounds better to me.  monitoring.sgml has a different way
of wording what looks like the same thing for pg_stat_xact_*_tables:
"Ordinary users can only see all the information about their own
sessions (sessions belonging to a role that they are a member of)".

So you could say instead something like: this information is only
visible to superusers, roles with privileges of the pg_read_all_stats
role, and the user owning the sessionS being reported on (including
sessions belonging to a role that they are a member of).
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: ccache, MSVC, and meson
Next
From: Andres Freund
Date:
Subject: Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?