Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
