On Wed, Jul 21, 2021 at 3:52 PM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > > On Tue, Jul 13, 2021 at 9:03 PM vignesh C <vignes...@gmail.com> wrote: > > > > On Wed, May 12, 2021 at 2:27 AM Robert Haas <robertmh...@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?
As Robert pointed out, this idea is based on Mark Dilger's proposal. Mark Dilger is already handling many of them at [1]. I'm proposing this patch only for server debugging functionalities based on Robert's suggestions at [2]. [1] - https://commitfest.postgresql.org/33/3223/ [2] - https://www.postgresql.org/message-id/CA%2BTgmoZz%3DK1bQRp0Ug%3D6uMGFWg-6kaxdHe6VSWaxq0U-YkppYQ%40mail.gmail.com Regards, Vignesh
