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  (Yugo Nagata <nagata@sraoss.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] outfuncs.c utility statement support
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] pgrowlocks relkind check