Oliver Jowett <oliver@opencloud.com> writes:
> We want to block thread 1 at the point marked (*) until we know the cancel
> has been processed and it is safe to send another query. However, looking at
> the backend code query-cancel is implemented by B sending a signal to A, and
> if A is not executing a query the signal is silently eaten. So I'm not sure
> how to eliminate this race as we have no way of working out when the signal
> has arrived in the above case.
When JDBC issues a cancel request, does it simply fire off a few bytes
and close the connection? You could make things a lot closer to
synchronous if you wait for the postmaster to drop the connection,
instead. That would guarantee that the postmaster has completed
executing kill(). I suppose actual delivery of the signal to the
backend might not have happened yet, but it's hard to believe that
it could be postponed past the backend's next successful execution of
recv().
regards, tom lane