Postgres Pro
Downloads
Home   >   mailing lists

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?gr - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?gr
Date
Msg-id YWY1nZGAswlNPxhY@paquier.xyz
Whole thread Raw
In response to Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?  (Stephen Frost <sfrost@snowman.net>)
Responses Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?gr  ("Bossart, Nathan" <bossartn@amazon.com>)
Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?gr  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
Tree view 
On Tue, Oct 12, 2021 at 08:33:19PM -0400, Stephen Frost wrote:
> I would think we would do both…. That is- move to using GRANT/REVOKE, and
> then just include a GRANT to pg_read_all_stats.
>
> Or not. I can see the argument that, because it just goes into the log,
> that it doesn’t make sense to grant to a predefined role, since that role
> wouldn’t be able to see the results even if it had access.

I don't think that this is a bad thing to remove the superuser() check
and replace it with a REVOKE FROM PUBLIC in this case, but linking the
logging of memory contexts with pg_read_all_stats does not seem right
to me.
--
Michael
Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [RFC] building postgres with meson
Next
From: Mark Simon
Date:
Subject: Feature Request: Allow additional special characters at the beginning of the name.