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

From Bossart, Nathan
Subject Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats().
Date
Msg-id 33F34F0C-BB16-48DE-B125-95D340A54AE8@amazon.com
Whole thread Raw
In response to Allow pg_signal_backend members to use pg_log_backend_memory_stats().  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats().  (Michael Paquier <michael@paquier.xyz>)
Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats().  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On 10/23/21, 12:57 PM, "Jeff Davis" <pgsql@j-davis.com> wrote:
> pg_signal_backend seems like the appropriate predefined role, because
> pg_log_backend_memory_contexts() is implemented by a sending signal.

This seems reasonable to me.  The stated reason in the original commit
message for keeping it restricted to superusers is because of the
denial-of-service risk, but if you've got pg_signal_backend, you can
already terminate sessions.  The predefined roles documentation notes
that members of pg_signal_backend cannot signal superuser-owned
backends, but AFAICT pg_log_backend_memory_contexts() has no such
restriction at the moment.  Should we add this?

Otherwise, presumably we will need to update func.sgml and the comment
above pg_log_backend_memory_contexts() in mcxtfuncs.c.

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.

Nathan


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: How to retain lesser paths at add_path()?
Next
From: Jeff Davis
Date:
Subject: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.