Re: Async PQgetResult() question.

From: Matthew Hagerty <mhagerty(at)voyager(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Async PQgetResult() question.
Date: 2001-07-07 19:02:30
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

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/
>getResult loop.

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


In response to


Browse pgsql-hackers by date

  From Date Subject
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.