|From:||Matthew Hagerty <mhagerty(at)voyager(dot)net>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: Async PQgetResult() question.|
|Views:||Raw Message | Whole Thread | Download mbox|
At 02:13 PM 7/7/2001 -0400, Tom Lane wrote:
>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.
If I don't call PQsetnonblocking() will that affect any of the async
functions I'm dealing with? I might have insert queries that are rather
large and I'm not sure how big my kernel's buffers are (and surely it will
be different on other OSes.)
> > 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/
Yup, I think that is what I was misunderstanding. I'll modify my loop and
see how it goes.
>(3) PQconsumeInput never blocks. Period. PQgetResult can block, but
>it promises not to if an immediately prior PQisBusy returned 0.
> regards, tom lane
|Next Message||Tom Lane||2001-07-07 19:15:18||Re: Re: [GENERAL] Vacuum and Transactions|
|Previous Message||Tom Lane||2001-07-07 18:13:44||Re: Async PQgetResult() question.|