On Thu, Oct 28, 2010 at 11:15 AM, A.M. <agentm@xxxxxxxxxxxxxxxxxxxxx> wrote:
Hm- I'm not sure how the async API will allow you to cancel queries. In PostgreSQL, query canceling is implemented by opening a second connection and passing specific data which is received from the first connection (effectively sending a cancel signal to the connection instead of a specific query). This implementation is necessitated by the fact that the PostgreSQL backend isn't asynchronous.
On Oct 28, 2010, at 11:08 AM, Michael Clark wrote:
> Hello all.
>
> Thanks a lot for the responses, they are appreciated.
>
> I think I now understand the folly of my loop, and how that was negatively
> impacting my "test".
>
> I tried the suggestion Alex and Tom made to change my loop with a select()
> and my results are now very close to the non-async version.
>
> The main reason for looking at this API is not to support async in our
> applications, that is being achieved architecturally in a PG agnostic way.
> It is to give our PG agnostic layer the ability to cancel queries.
> (Admittedly the queries I mention in these emails are not candidates for
> cancelling...).
Even if you cancel the query, you still need to consume the socket input. Query cancellation is available for libpq both in sync and async modes.
Oh. I misunderstood that.
I guess I can have one thread performing the query using the non async PG calls, then from another thread issue the cancellation. Both threads accessing the same PGconn ?
I am glad I added that extra bit of info in my reply, and that your caught it!!
Thank you!
Michael.
