On Thu, Oct 28, 2010 at 11:15 AM, A.M.
<agentm@themactionfaction.com> wrote:
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...).
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.
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.
