Re: Printing backtrace of postgres processes - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Printing backtrace of postgres processes
Date
Msg-id CALj2ACXK=mY97ND6aiQt24JUqGBEeXH0zht5=E1Q532gf8NehQ@mail.gmail.com
Whole thread Raw
In response to Re: Printing backtrace of postgres processes  (vignesh C <vignesh21@gmail.com>)
Responses Re: Printing backtrace of postgres processes
List pgsql-hackers
On Tue, Jul 13, 2021 at 9:03 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Wed, May 12, 2021 at 2:27 AM Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > 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.

I see that there are a good number of user functions that are
accessible only by superuser (I searched for "if (!superuser())" in
the code base). I agree with the intention to not overload the
superuser anymore and have a few other special roles to delegate the
existing superuser-only functions to them. In that case, are we going
to revisit and reassign all the existing superuser-only functions?

Regards,
Bharath Rupireddy.



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: postgres_fdw - make cached connection functions tests meaningful
Next
From: David Rowley
Date:
Subject: Re: Micro-optimizations to avoid some strlen calls.