On Tue, Jun 07, 2022 at 10:08:21PM +0900, Ian Lawrence Barwick wrote:
> 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
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 :
>
> 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
>
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 h
On Sat, May 28, 2022 at 05:50:35PM +0900, Michael Paquier wrote:
> On Wed, May 25, 2022 at 01:04:04PM +0900, Michael Paquier wrote:
>> Good point. So this would give, to be exact:
>> "This information is only visible to superusers, roles with privileges
>> of the pg_read_all_stats role, and and th
On Wed, May 25, 2022 at 01:04:04PM +0900, Michael Paquier wrote:
> Good point. So this would give, to be exact:
> "This information is only visible to superusers, roles with privileges
> of the pg_read_all_stats role, and and the user owning the sessionS
> being reported on (including sessions bel
On Mon, May 23, 2022 at 09:41:42AM -0700, Nathan Bossart wrote:
> I think we need to be careful about saying "member of" when we really mean
> "roles with privileges of." Unless I am mistaken, role membership alone is
> not sufficient for viewing this information. You also need to inherit the
> r
On Mon, May 23, 2022 at 08:53:24AM +0900, Michael Paquier wrote:
> On Sun, May 22, 2022 at 01:26:08PM -0700, Nathan Bossart wrote:
>> ... superusers, roles with privileges of the pg_read_all_stats role,
>> and roles with privileges of the user owning the session being reported
>> on
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
> reporte
On Sun, May 22, 2022 at 09:59:47AM +0900, Michael Paquier wrote:
> +visible to superusers, roles with privileges of the
> +pg_read_all_stats role, and roles with privileges of
> +the user owning the session being reported on, so it should not
> +represent a security risk. Only super
On Sat, May 21, 2022 at 11:57:43AM -0700, Nathan Bossart wrote:
> Sorry, I should've noticed this yesterday. This should probably follow
> 6198420's example and say "roles with privileges of the pg_read_all_stats
> role" instead of "members of the pg_read_all_stats role."
Yes, I saw that, but tha
On Sat, May 21, 2022 at 12:28:58PM +0900, Michael Paquier wrote:
> Indeed, it is a good idea to add this information. Will apply and
> backpatch accordingly.
Sorry, I should've noticed this yesterday. This should probably follow
6198420's example and say "roles with privileges of the pg_read_all
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.
--
Michael
signature.asc
Description: PGP signature
On Fri, May 20, 2022 at 03:17:29PM +0900, Ian Lawrence Barwick wrote:
> It seems reasonable to mention here that the information is also visible to
> members of "pg_read_all_stats", similar to what is done in the
> pg_stat_statements
> docs [2].
>
> [2]
> https://www.postgresql.org/docs/current/p
Hi
Regarding the visibility of query information, the description for
"track_activities" [1] says:
> Note that even when enabled, this information is not visible to all users,
> only to superusers and the user owning the session being reported on, so it
> should not represent a security risk.
[1
14 matches
Mail list logo
