Re: Printing backtrace of postgres processes

On Thu, May 6, 2021 at 3:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)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.

--
Robert Haas
EDB: http://www.enterprisedb.com