Re: Function to kill backend

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

From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Magnus Hagander <mha@sollentuna.net>, pgsql-hackers@postgresql.org
Date: 2004-04-06T18:12:08Z
Lists: pgsql-hackers
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.

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