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