On Mon, Sep 15, 2003 at 12:01:47PM -0400, Tom Lane wrote:
> 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?
Indeed it does.
> 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().
That sounds reasonable. I'll put together a patch to do that.
Thanks.
-O
