Re: Allow non-superuser to cancel superuser tasks.
От | Nathan Bossart |
---|---|
Тема | Re: Allow non-superuser to cancel superuser tasks. |
Дата | |
Msg-id | 20240410150034.GA1673069@nathanxps13 обсуждение исходный текст |
Ответ на | Re: Allow non-superuser to cancel superuser tasks. (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Allow non-superuser to cancel superuser tasks.
|
Список | pgsql-hackers |
On Wed, Apr 10, 2024 at 07:58:39AM +0900, Michael Paquier wrote: > On Wed, Apr 10, 2024 at 12:52:19AM +0300, Kirill Reshke wrote: >> On Tue, 9 Apr 2024 at 08:53, Michael Paquier <michael@paquier.xyz> wrote: >>> 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. >> >> Good catch. Thanks. I think we need to update the error message to not >> leak backend type info. > > Yep, that's necessary I am afraid. Isn't it relatively easy to discover this same information today via pg_stat_progress_vacuum? That has the following code: /* Value available to all callers */ values[0] = Int32GetDatum(beentry->st_procpid); values[1] = ObjectIdGetDatum(beentry->st_databaseid); I guess I'm not quite following why we are worried about leaking whether a backend is an autovacuum worker. >>> 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. >> >> Ok. What would be a good choice? Is `pg_signal_autovacuum_worker` good >> enough? > > Sounds fine to me. Perhaps others have an opinion about that? WFM -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: