Re: Function to kill backend

Bruce Momjian <pgman@candle.pha.pa.us>

From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2004-04-03T02:26:52Z
Lists: 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, Pennsylvania 19073