Re: Async PQgetResult() question.

At 11:44 PM 7/7/2001 -0400, Tom Lane wrote:
>Matthew Hagerty <mhagerty@voyager.net> writes:
> > So then how would I code for the exception, i.e. the backend goes down 
> just
> > before or during my call to PQsendQuery()?  If I am non-blocking then I 
> can
> > determine that my query did not go (PQsendQuery() or PQflush() returns an
> > error) and attempt to recover.
>
>This is the nasty part of any async client, all right.  The case of a
>backend crash doesn't bother me particularly: in the first place, you'll
>get back a "connection closed" failure quickly, and in the second place,
>backend crashes while absorbing query text (as opposed to while
>executing a query) are just about unheard of.  However, the possibility
>of loss of network connectivity is much more dire: it's plausible, and
>in most cases you're looking at a very long timeout before the kernel
>will decide that the connection is toast and report an error to you.
>
>I'm unconvinced, however, that using PQsetnonblocking improves the
>picture very much.  Unless the database operations are completely
>noncritical to what your app is doing, you're going to be pretty
>much dead in the water anyway with a lost connection :-(
>
>In the end you pays your money and you takes your choice.  I do
>recommend reading my past rants about why PQsetnonblocking is broken
>(circa Jan 2000, IIRC) before you put any faith in it.  If you end
>up deciding that it really is something you gotta have, maybe you'll
>be the one to do the legwork to make it reliable.
>
>                         regards, tom lane


Well, I guess sending a query will have to be my weak link for the moment, 
heck, that's why we have version releases, right? ;)  I'll take your advise 
and disable PQsetnonblocking for now, but I would like to read your rants 
and maybe (if I think I can muster the courage), look into fixing 
PQsetnonblocking.  I have never dug around for an IIRC archive before, 
might you recommend one that contains your rants?

Thanks,
Matthew