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 |
Message-ID: | 5.0.2.1.2.20010707145320.02361610@pop.voyager.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
Thanks,
Matthew
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. |