From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | "Leung, Anthony" <antholeu(at)amazon(dot)com> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow non-superuser to cancel superuser tasks. |
Date: | 2024-04-09 05:53:00 |
Message-ID: | ZhTXvFKMkdWDXqG0@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 08, 2024 at 05:42:05PM +0000, Leung, Anthony wrote:
> Are you suggesting that we check if the backend is B_AUTOVAC in
> pg_cancel/ terminate_backend? That seems a bit unclean to me since
> pg_cancel_backend & pg_cancel_backend does not access to the
> procNumber to check the type of the backend.
>
> IMHO, we can keep SIGNAL_BACKEND_NOAUTOVACUUM but just improve the
> errmsg / errdetail to not expose that the backend is an AV
> worker. It'll also be helpful if you can suggest what errdetail we
> should use here.
The thing is that you cannot rely on a lookup of the backend type for
the error information, or you open yourself to letting the caller of
pg_cancel_backend or pg_terminate_backend know if a backend is
controlled by a superuser or if a backend is an autovacuum worker.
And they may have no access to this information by default, except if
the role is a member of pg_read_all_stats able to scan
pg_stat_activity. An option that I can think of, even if it is not
the most elegant ever, would be list all the possible system users
that can be used in the errdetail under a single SIGNAL_BACKEND_NO*
state.
In the case of your patch it would mean to mention both
pg_signal_backend and pg_signal_autovacuum.
The choice of pg_signal_autovacuum is a bit inconsistent, as well,
because autovacuum workers operate like regular backends. This name
can also be confused with the autovacuum launcher.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-04-09 05:55:39 | Re: post-freeze damage control |
Previous Message | Parag Paul | 2024-04-09 05:52:09 | Issue with the PRNG used by Postgres |