Re: docs: mention "pg_read_all_stats" in "track_activities" description

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: docs: mention "pg_read_all_stats" in "track_activities" description
Дата
Msg-id YorM9Kv4bFVBoCsI@paquier.xyz
обсуждение исходный текст
Ответ на Re: docs: mention "pg_read_all_stats" in "track_activities" description  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: docs: mention "pg_read_all_stats" in "track_activities" description  (Nathan Bossart <nathandbossart@gmail.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: ccache, MSVC, and meson
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?