Re: Async PQgetResult() question.

Matthew Hagerty <mhagerty(at)voyager(dot)net> writes:
> Only applications that have used PQsetnonblocking have a need for this."

> Since I use PQsetnonblocking(), I included PQflush().

Hmm. My opinions about the PQsetnonblocking patch are on record:
it's broken and needs fundamental redesign before it has any chance
of operating reliably. Unless you are sending queries whose text is
many kB (more than your kernel will buffer for one send() call),
I recommend you not use it.

However, that only affects output, not input.

> I wrote a small test program and at this point (after
> reading the first result) I looped back to my select, but the socket never
> went read-ready again, so the last
> PQconsumeInput()/PQisBusy()/PQgetResults() was never called to receive the
> NULL response from PQgetResult(), which is how the docs say I know the
> query is done.

> But if I loop back to PQconsumeInput()/PQisBusy(), then I am effectively
> blocking since I have no way to know that PQconsumeInput() won't block or
> that the PQisBusy() will ever return zero again.

(1) No, you don't need to repeat the PQconsumeInput, unless select still
says read-ready. (You could call it again, but there's no point.)

(2) You should repeat PQisBusy && PQgetResult until one of them fails,
however. What you're missing here is that a single TCP packet might
provide zero, one, or more than one PQgetResult result. You want to
loop until you've gotten all the results you can get from the current
input packet. Then you go back to select(), and eventually you'll see
more backend input and you do another consumeInput and another isBusy/
getResult loop.

(3) PQconsumeInput never blocks. Period. PQgetResult can block, but
it promises not to if an immediately prior PQisBusy returned 0.

regards, tom lane