From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Dmitry Samonenko <shreddingwork(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Fwd: libpq: indefinite block on poll during network problems |
Date: | 2014-05-30 16:19:55 |
Message-ID: | 20140530161954.GC19553@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, May 30, 2014 at 07:48:00PM +0400, Dmitry Samonenko wrote:
> > BTW, you might consider using libpq's nonblock mode to push the waiting
> > out to the application level, and then you could just decide when you've
> > waited too long for yourself.
> >
> Do you mean PQsendQuery / PQisBusy / PQgetResult? Well, I wouldn't start
> this discussion if that was an option. Adopting async command processing
> would lead to starting client from scratch.
I don't think the suggestion is to move to async command processing. I
think the suggestion is to use those methods to make a
PGgetResultWithTimeout() that does what you want.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
-- Arthur Schopenhauer
From | Date | Subject | |
---|---|---|---|
Next Message | reiner peterke | 2014-05-30 16:49:02 | unable to build postgres-9.4 in os x 10.9 with python |
Previous Message | Chris Hanks | 2014-05-30 16:16:02 | row_to_json on a subset of columns. |