On 12-Dec-06, at 4:30 PM, Tom Lane wrote:
> "Brendan O'Shea" <brendanoshea(at)comcast(dot)net> writes:
>> We have discovered a situation where the statement_timeout is not =
>> honored for broken connections. If a connection is in the process
>> of =
>> returning results to the client and the connection is severed (for =
>> example, network cable on client is unplugged) then the query
>> continues =
>> to run on the server even after the statement_timeout is exceeded.
>
> Well, the backend is blocked on a write() to the socket and cannot
> abort
> that without bollixing the connection completely (i.e., loss of
> message
> synchronization). So I think waiting until the TCP stack declares
> failure is an appropriate response. If you want faster TCP failure,
> see whether your TCP stack allows timeout adjustments.
>
> Note that the query is not "running" in the sense of consuming any
> meaningful CPU or I/O resources in this state ...
Of course, the query may have locks that block other meaningful
operations. When a hung connection like this occurs on our server, I
have resorted to using gdb to return from the write() method. Is this
an acceptable way to kill the connection on the server side?