"Tom Lane" <tgl@xxxxxxxxxxxxx>
"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 ...
regards, tom lane
I noticed something odd about the query that is still active on the severed
connection. If the statement_timeout on the query is exceeded and I send a
cancel signal then the query still stays active, it does not respond to
cancel or kill TERM signals. But if I send the cancel signal before the
statement timeout is exceeded on the severed connection then the query is
cancelled and the status goes back to 'idle'. Can this behavior be changed
so that the cancel signal works regardless of whether or not the statement
timeout has been exceeded? This would be useful so that we can free
up the locks used by the active query that are interfering with the vacuum
daemon.
Thanks,
Brendan
