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 по дате отправления: