"Brendan O'Shea" <brendanoshea@comcast.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 ...
regards, tom lane