Re: Printing backtrace of postgres processes
От | Bharath Rupireddy |
---|---|
Тема | Re: Printing backtrace of postgres processes |
Дата | |
Msg-id | CALj2ACXK=mY97ND6aiQt24JUqGBEeXH0zht5=E1Q532gf8NehQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Printing backtrace of postgres processes (vignesh C <vignesh21@gmail.com>) |
Ответы |
Re: Printing backtrace of postgres processes
|
Список | 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 по дате отправления: