Re: [HACKERS] Function to kill backend
От | Magnus Hagander |
---|---|
Тема | Re: [HACKERS] Function to kill backend |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE34BF13@algol.sollentuna.se обсуждение исходный текст |
Ответы |
Re: [HACKERS] Function to kill backend
|
Список | pgsql-patches |
>> 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
В списке pgsql-patches по дате отправления: