Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers
| От | Michael Paquier |
|---|---|
| Тема | Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers |
| Дата | |
| Msg-id | CAB7nPqQF-U0-EsinR=Gyoigi9MTvFtb1iC4JjqM9we9uJN-YCw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers (andres@anarazel.de (Andres Freund)) |
| Ответы |
Re: [HACKERS] pg_terminate_backend can terminate background workersand autovacuum launchers
|
| Список | pgsql-hackers |
On Thu, Jun 22, 2017 at 11:52 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2017-06-22 11:49:47 +0900, Yugo Nagata wrote:
>> I agree that we can kill theses processes by the OS command. However,
>> It seems to me that pg_{cancel,terminate}_backend don't need to be able to
>> kill processes except for client backends because we can do same thing by
>> the OS command if necessary, and acutually these functions cannot kill
>> most other processes, for example, background writer. Are the autovacuum
>> launcher and background worker special for these functions?
>
> I strongly disagree with this - I think it's quite useful to be able to
> kill things via SQL that can hold lock on database objects. I'm not
> seeing which problem would be solved by prohibiting this?
+1. Controlling them as of now is useful, particularly now that all
processes show wait events, even auxiliary ones (though not
signal-able). Different thought, but I'd love to see a SQL function
that allows triggering SIGHUP on a specific process, like an
autovacuum worker to change its cost parameters. There is
pg_reload_conf() to do so but that's system-wide.
--
Michael
В списке pgsql-hackers по дате отправления: