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