Niall Ross <niallfr@btinternet.com> writes:
> Am I misunderstanding something? My experience with using Postgres, and
> my reading of the documents, is that a new statement, but not a new
> connection, is needed to cancel a statement on that connection. The
> cancel is signalled by a fresh statement using the same connection (and
> specifically that connection's PID and Key).
Uh, no, that's not how it works at all. PQcancel() involves opening a
fresh connection to the postmaster, which will then send SIGINT to the
backend process you're originally connected to.
Also, looking again at the PQcancel code, I'm unsure that there is any
actual race condition here. The comments therein quoth
* Wait for the postmaster to close the connection, which indicates that
* it's processed the request. Without this delay, we might issue another
* command only to find that our cancel zaps that command instead of the
* one we thought we were canceling. Note we don't actually expect this
* read to obtain any data, we are just waiting for EOF to be signaled.
which means that by the time the PQcancel call returns, the SIGINT has
been sent. I did speculate upthread that delivery of that signal might
be asynchronous, but that was just speculation. Even if there was some
delay, the backend would ignore the signal unless it arrived later than
the first byte of the next client request. So it seems a bit hard to
credit that you would have a practical problem unless your application
were to issue a new command while PQcancel was still executing ... and if
it does, I maintain that's an application bug not a protocol problem.
regards, tom lane
