From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <mha(at)sollentuna(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Function to kill backend |
Date: | 2004-04-06 18:12:08 |
Message-ID: | 200404061812.i36IC8K15902@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-04-06 18:38:33 | Re: Function to kill backend |
Previous Message | Bruce Momjian | 2004-04-06 18:09:57 | Re: [HACKERS] logging statement levels |