Re: Function to kill backend

pgman wrote:
> Josh Berkus wrote:
> > Tom,
> > 
> > > I don't think it's an open-and-shut decision as to whether people
> > > actually *need* to do session kills (as opposed to query/transaction
> > > kills).  The arguments presented so far are not convincing to my mind,
> > > certainly not convincing enough to buy into a commitment to do whatever
> > > it takes to support that.
> > 
> > Hmmm ... well, I can make a real-world case from my supported apps for 
> > transaction/statement kills.   But my support for session kills is just 
> > hypothetical; any  time I've had to kill off sessions, it's because I had to 
> > shut the database down, and that's better done from the command line.
> > 
> > My web apps which need to manage the number of connections do it through their 
> > connection pool.
> > 
> > So I would vote for Yes on SIGINT by XID, but No on SIGTERM by PID, if Tom 
> > thinks there will be any significant support & troubleshooting involved for 
> > the latter.
> > 
> > Unless, of course, someone can give us a real business case that they have 
> > actually encountered in production.
> 
> Someone already posted some pseudocode where they wanted to kill idle
> backends, perhaps as part of connection pooling.

Tom, if you have concerns about SIGTERM while other backends keep
running, would you share those.  (Holding locks, shared memory?)  I
looked at die(), and it seemed pretty safe to me.  It just sets some
variables and returns.  It is not like quickdie that calls exit().

If there is a problem, maybe we can fix it, or perhap have the kill
function use SIGINT, then wait for the query to cancel, then SIGTERM.

--  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