Josh Berkus wrote:
> Bruce,
>
> > Someone already posted some pseudocode where they wanted to kill idle
> > backends, perhaps as part of connection pooling.
>
> I'm not talking about code. I'm talking about a *reason*.
>
> i.e.: "I'm administrator of the blah-blah project. We had a lot of trouble
> managing idle connections to PG because of blah-blah. A function to kill
> off idle connctions would really help us becuase blah-blah-blah."
>
> So far, all we've heard in favor of SIGTERM-by-PID are *hypothetical* cases.
> Now Tom's telling us that there is a real cost attached to having this
> feature. Before we do it anyway, I want to be convinced that someone really
> needs it. It is *not* our practice to add features "just because we can."
>
> Otherwise, I'll stick by my assertion that idle connection management should
> be done in the middleware and NOT by psql.
OK, you have a runaway report. You want to stop it. Query cancel is
only going to stop the current query, and once you do that the next
query is fed in so there is no way to actually stop the report,
especially if the report is not being run from the same machine as the
server (you can't kill the report process). How do you stop it without
SIGTERM? You don't want to shut down the postmaster.
In fact, query cancel is actually more dangerous in this case because
unless the report is designed to handle statement failures, it might
just keep running and produce incorrect results because you canceled
some random queries in the report. (I am thinking specifically of a
psql batch job here.)
-- 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