Skip site navigation (1) Skip section navigation (2)

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
Message-ID: 5.0.2.1.2.20010707145320.02361610@pop.voyager.net (view raw or flat)
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


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-07-07 19:15:18
Subject: Re: Re: [GENERAL] Vacuum and Transactions
Previous:From: Tom LaneDate: 2001-07-07 18:13:44
Subject: Re: Async PQgetResult() question.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group