From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats(). |
Date: | 2021-10-23 20:42:29 |
Message-ID: | 33F34F0C-BB16-48DE-B125-95D340A54AE8@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/23/21, 12:57 PM, "Jeff Davis" <pgsql(at)j-davis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2021-10-23 21:45:02 | Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT. |
Previous Message | Greg Stark | 2021-10-23 20:02:40 | Re: How to retain lesser paths at add_path()? |