Thread: Re: [HACKERS] Function to kill backend

>> OK, I see your point.  Can anyone remember why this was needed?  I
>> remember Magnus wanted query cancel, but what was the logic
>for session
>> termination?
>
>I think the argument for it went along the lines of "what if you've got
>a misbehaving client that continually issues expensive queries, so
>canceling any one query doesn't help?"  I found this unconvincing, as
>a client that obstreperous might simply reconnect and start issuing the
>same queries again; so having a session-kill tool doesn't
>really get you
>much further.  I recall being voted down though ...

That's not quite the argument I think I had :-) But withuot being able
to kill the backends, there just no way for me to handle the sitaution
when I have a hundred clients eating up all available connections and/or
memory, just sitting idle, because of some freak bug in a client. Yes,
if they keep reconnecting it will not save me. But if it's just a client
that does a new connect say every hour and then forgets to close the old
one, I can easily manage the situation (until I can fix the client. Or,
which probably takes a lot more time, convince a vendor that this is
actually a problem in the client).

There has to be *some* way of closing a connection. I'd be happy with
being able to do it on a backend that sits idle (I can always send it
the cancel query, then wait until it does it's job and goes back to
being idle, and then kill it). But some way of doing that is necessary,
IMHO.

Don't know exactly what Bruce's patch did, but perhaps if this
restriction can be put on it the dangerous parts of the patch can be
reverted without removing the capability to terminate a backend that is
idle?

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:
> That's not quite the argument I think I had :-) But withuot being able
> to kill the backends, there just no way for me to handle the sitaution
> when I have a hundred clients eating up all available connections and/or
> memory, just sitting idle, because of some freak bug in a client. Yes,
> if they keep reconnecting it will not save me. But if it's just a client
> that does a new connect say every hour and then forgets to close the old
> one, I can easily manage the situation (until I can fix the client. Or,
> which probably takes a lot more time, convince a vendor that this is
> actually a problem in the client).

How often does that situation really come up?  This sounds more like
a theoretical concern than something that actually happens on a regular
basis.

Would you use a kill operation in the way you describe above if you knew
that it had, say, a 1% chance of causing a database-wide PANIC each time
you used it?

The odds of a problem are probably a great deal less than 1%, especially
if the backend is sitting idle.  But they're not nil, and I don't think
we have the resources to make them nil in this release cycle.
Therefore I'm uneager to provide this feature simply because of "it
might be nice to have" arguments.  There's a lot of other stuff that is
higher on the priority list, IMHO anyway.

> Don't know exactly what Bruce's patch did, but perhaps if this
> restriction can be put on it the dangerous parts of the patch can be
> reverted without removing the capability to terminate a backend that is
> idle?

You have that backwards.  The dangerous part is killing a single backend.
Bruce's patch was an unsuccessful attempt to make it less dangerous.

Note also that what's at stake is not whether you can do this at all.
You can issue manual SIGTERMs all you like.  What's at stake is whether
we promote the feature into an easy-to-use, presumably supported
operation.  My real complaint here is that I don't think we are prepared
to support it.

            regards, tom lane

> Would you use a kill operation in the way you describe above if you knew
> that it had, say, a 1% chance of causing a database-wide PANIC each time
> you used it?
>
> The odds of a problem are probably a great deal less than 1%, especially
> if the backend is sitting idle.  But they're not nil, and I don't think
> we have the resources to make them nil in this release cycle.
> Therefore I'm uneager to provide this feature simply because of "it
> might be nice to have" arguments.  There's a lot of other stuff that is
> higher on the priority list, IMHO anyway.

Can we keep the cancel query function and just lose the kill one?

Chris

Christopher Kings-Lynne wrote:
> > Would you use a kill operation in the way you describe above if you knew
> > that it had, say, a 1% chance of causing a database-wide PANIC each time
> > you used it?
> >
> > The odds of a problem are probably a great deal less than 1%, especially
> > if the backend is sitting idle.  But they're not nil, and I don't think
> > we have the resources to make them nil in this release cycle.
> > Therefore I'm uneager to provide this feature simply because of "it
> > might be nice to have" arguments.  There's a lot of other stuff that is
> > higher on the priority list, IMHO anyway.
>
> Can we keep the cancel query function and just lose the kill one?

No one is suggesting removing cancel so that one is fine.  Sending a
single to cancel is done all the time already so that should be fine.

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

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> Can we keep the cancel query function and just lose the kill one?

That would be my druthers.  I have no problem with the cancel function.

            regards, tom lane