On Thu, Oct 28, 2010 at 11:15 AM, A.M. <age...@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.
