Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats().
От | Bossart, Nathan |
---|---|
Тема | Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats(). |
Дата | |
Msg-id | 33F34F0C-BB16-48DE-B125-95D340A54AE8@amazon.com обсуждение исходный текст |
Ответ на | Allow pg_signal_backend members to use pg_log_backend_memory_stats(). (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats().
Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats(). |
Список | 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 по дате отправления: