On Wed, May 12, 2021 at 2:27 AM Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, May 6, 2021 at 3:31 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Andres Freund <and...@anarazel.de> writes: > > > On 2021-05-06 14:56:09 -0400, Tom Lane wrote: > > >> If we think it's worth having a predefined role for, OK. However, > > >> I don't like the future I see us heading towards where there are > > >> hundreds of random predefined roles. Is there an existing role > > >> that it'd be reasonable to attach this ability to? > > > > > It does seem like it'd be good to group it in with something > > > else. There's nothing fitting 100% though. > > > > I'd probably vote for pg_read_all_data, considering that much of > > the concern about this has to do with the possibility of exposure > > of sensitive data. I'm not quite sure what the security expectations > > are for pg_monitor. > > Maybe we should have a role that is specifically for server debugging > type things. This kind of overlaps with Mark Dilger's proposal to try > to allow SET for security-sensitive GUCs to be delegated via > predefined roles. The exact way to divide that up is open to question, > but it wouldn't seem crazy to me if the same role controlled the > ability to do this plus the ability to set the GUCs > backtrace_functions, debug_invalidate_system_caches_always, > wal_consistency_checking, and maybe a few other things.
+1 for the idea of having a new role for this. Currently I have implemented this feature to be supported only for the superuser. If we are ok with having a new role to handle debugging features, I will make a 002 patch to handle this. Regards, Vignesh