Re: Should PQconsumeInput/PQisBusy be expensive to use?

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