Re: Function to kill backend
От | Bruce Momjian |
---|---|
Тема | Re: Function to kill backend |
Дата | |
Msg-id | 200404030226.i332QqC29724@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Function to kill backend (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Function to kill backend
|
Список | pgsql-hackers |
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > Tom Lane wrote: > >> it would definitely need to be a lot more constrained than > >> send-any-signal-to-any-postgres-process ... even for a superuser, > >> that's a mighty fat-gauge foot-gun. > > > What sort of constraints do you have in mind? > > I'd limit it to SIGINT (query cancel) and SIGTERM (fast shutdown), > and I'm not even real sure about SIGTERM. That facility is designed to > work in the case of shutting down all backends together --- I'm not sure > I want to promise that it behaves pleasantly to SIGTERM one backend and > leave the rest going. Nor do I see a real good use-case for it. > > Also, no killing processes that aren't regular backends (eg, the > bgwriter, the stats processes, and most especially the postmaster). > > Another point is that killing by PID is not necessarily what you want to > do --- kill by transaction ID might be a better API, especially for > query-cancel cases. Seems like useful functionality. Right now, how does an administrator kill another backend from psql? They can't. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: