From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Statement.cancel() may cancel queries in the future |
Date: | 2003-09-15 22:07:45 |
Message-ID: | 20030915220743.GA11008@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Mon, Sep 15, 2003 at 12:01:47PM -0400, Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-09-15 22:17:36 | Re: Statement.cancel() may cancel queries in the future |
Previous Message | Kris Jurka | 2003-09-15 17:14:17 | Re: Bug #814 |