Re: Async PQgetResult() question.

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

Matthew Hagerty <mhagerty(at)voyager(dot)net> writes:
> If I don't call PQsetnonblocking() will that affect any of the async
> functions I'm dealing with?

PQsetnonblocking has nothing to do with the
PQconsumeInput/PQisBusy/PQgetResult family of functions. The point of
the latter is to avoid blocking while waiting for input from the
database. The point of PQsetnonblocking is to avoid blocking while
sending stuff to the database.

Now in a TCP environment, the only way send() is going to block is if
you send more stuff than there's currently room for in your kernel's
networking buffers --- which typically are going to be hundreds of K.
I could see needing PQsetnonblocking if you need to avoid blocking
while transmitting COPY IN data to the database ... but for queries
it's harder to credit. Also, unless you are sending more than one
query in a query string, the backend is going to be absorbing the
data as fast as it can anyway; so even if you do block it's only
going to be for a network transit delay, not for database processing.

Personally I've done quite a bit of asynchronous-application coding with
PQconsumeInput &friends, but never felt the need for PQsetnonblocking.
This is why I've not been motivated to try to fix its problems...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-07-07 20:14:01 Re: Async PQgetResult() question.
Previous Message Tom Lane 2001-07-07 19:15:18 Re: Re: [GENERAL] Vacuum and Transactions