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

From Ian Lawrence Barwick
Subject Re: docs: mention "pg_read_all_stats" in "track_activities" description
Date
Msg-id CAB8KJ=hGVTnCEVfZZHu49mveOps8hYaBS+KuhXUTehV05sCRkA@mail.gmail.com
Whole thread Raw
In response to Re: docs: mention "pg_read_all_stats" in "track_activities" description  (Michael Paquier <michael@paquier.xyz>)
Responses Re: docs: mention "pg_read_all_stats" in "track_activities" description
List pgsql-hackers
Hi

Apologies for the delayed response, was caught up in a minor life diversion
over the past couple of weeks.

2022年5月21日(土) 12:29 Michael Paquier <michael@paquier.xyz>:
>
> On Fri, May 20, 2022 at 04:08:37PM -0700, Nathan Bossart wrote:
> > LGTM
>
> Indeed, it is a good idea to add this information.  Will apply and
> backpatch accordingly.

Thanks!

2022年5月30日(月) 11:34 Michael Paquier <michael@paquier.xyz>:
>
> On Sat, May 28, 2022 at 06:10:31AM -0700, Nathan Bossart wrote:
> > Sorry, I missed this one earlier.  I'm okay with something along those
> > lines.  I'm still trying to think of ways to make the last part a little
> > clearer, but I don't have any ideas beyond what we've discussed upthread.
>
> Okay.  I have used the wording of upthread then.  Thanks!

A little late to the party, but as an alternative suggestion for the last
part:

  "... and users who either own the session being reported on, or who have
  privileges of the role to which the session belongs,"

so the whole sentence would read:

  Note that even when enabled, this information is only visible to superusers,
  roles with privileges of the pg_read_all_stats role, and users who either own
  the session being reported on or who have privileges of the role to which the
  session belongs, so it should not represent a security risk.

or with some parentheses to break it up a little:

  Note that even when enabled, this information is only visible to superusers,
  roles with privileges of the pg_read_all_stats role, and users who either own
  the session being reported on (or who have privileges of the role to which the
  session belongs), so it should not represent a security risk.

I'm not sure if it really improves on the latest committed change, so just a
suggestion.


Regards

Ian Barwick



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: broken regress tests on fedora 36
Next
From: Peter Eisentraut
Date:
Subject: JSON_TABLE output collations