At 03:46 PM 7/7/2001 -0400, Tom Lane wrote:
>Matthew Hagerty <mhagerty@voyager.net> writes:
> > If I don't call PQsetnonblocking() will that affect any of the async
> > functions I'm dealing with?
>
>PQsetnonblocking has nothing to do with the
>PQconsumeInput/PQisBusy/PQgetResult family of functions. The point of
>the latter is to avoid blocking while waiting for input from the
>database. The point of PQsetnonblocking is to avoid blocking while
>sending stuff to the database.
>
>Now in a TCP environment, the only way send() is going to block is if
>you send more stuff than there's currently room for in your kernel's
>networking buffers --- which typically are going to be hundreds of K.
>I could see needing PQsetnonblocking if you need to avoid blocking
>while transmitting COPY IN data to the database ... but for queries
>it's harder to credit. Also, unless you are sending more than one
>query in a query string, the backend is going to be absorbing the
>data as fast as it can anyway; so even if you do block it's only
>going to be for a network transit delay, not for database processing.
>
>Personally I've done quite a bit of asynchronous-application coding with
>PQconsumeInput &friends, but never felt the need for PQsetnonblocking.
>This is why I've not been motivated to try to fix its problems...
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. Otherwise, my server could block until
PQsendQuery() times out and returns an error. I guess it would depend on
how long PQsendQuery() waits to return if there is an error or problem with
the backend or the connection to the backend?
Matthew