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