Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats(). - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats().
Date
Msg-id YXSdwCaTSUuvt73I@paquier.xyz
Whole thread Raw
In response to Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats().  ("Bossart, Nathan" <bossartn@amazon.com>)
List pgsql-hackers
On Sat, Oct 23, 2021 at 08:42:29PM +0000, Bossart, Nathan wrote:
> Otherwise, presumably we will need to update func.sgml and the comment
> above pg_log_backend_memory_contexts() in mcxtfuncs.c.

Yes, the documentation of any SQL function whose hardcoded superuser()
check is removed needs a refresh to outline that its execution can be
GRANT-ed post-initialization, and it should also document which system
roles are able to use it.  See for instance pg_database_size(), that
mentions roles need to be a member of pg_read_all_stats.

> This is unrelated to this patch, but should we also consider opening
> up pg_reload_conf() and pg_rotate_logfile() to members of
> pg_signal_backend?  Those are the other "server signaling functions" I
> see in the docs.

Yes, there is that as well.

+CREATE ROLE testrole1 IN ROLE pg_signal_backend;
+CREATE ROLE testrole2;
Any role created in the regression test needs to be prefixed with
"regress_", or builds with -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS
will complain (I just add that by default to not fall into this trap
again).
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Refactoring: join MakeSingleTupleTableSlot() and MakeTupleTableSlot()
Next
From: Dmitry Dolgov
Date:
Subject: Re: MDAM techniques and Index Skip Scan patch