The following bug has been logged on the website:
Bug reference: 13518
Logged by: Niall Ross
Email address: niallfr@btinternet.com
PostgreSQL version: 9.3.1
Operating system: Mac OSX 10.9.5, Windows 7, Linux RHel 5.6
Description:
Postgres lacks a way to cancel a specific identified statement. Sending
CancelRequest cancels the current statement running on a connection. But
this means the current statement when the cancel reaches the server, _not_
the current statement when the cancel was sent. Thus we are caught between
a rock and a hard place when our system has to dismiss an
incompletely-processed statement, since the system cannot tell which of the
following applies.
- If the statement will run on the server for a while yet, we have time to
send cancel-on-server and will complete the dismiss quicker by doing so
(because we buffer, draining all messages for that statement from the
socket, and cancelling on server truncates the flow of messages).
- If the statement will soon finish anyway, the asynchronous
cancel-on-server can kill the _next_ statement on that connection, not the
one our system seeks to dismiss, exactly the opposite of what is wanted.
When dismissing a query, the aim is to do so as fast as possible. For a
long-running query, sending CancelRequest to the server is exactly what you
want, but until Postgres knows which session is meant, we can see no way for
an automatic system to do this safely (unless by a post-send delay,
defeating the aim, which is performance).
If CancelRequest could include a statement name (or other means of
identifying a statement) and did nothing if that statement was no longer
running by the time the server processed it, the usability of CancelRequest
would be significantly enhanced.