On 12-Dec-06, at 4:30 PM, Tom Lane wrote:
"Brendan O'Shea" <brendanoshea@xxxxxxxxxxx> 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?
