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

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 (view raw or flat)
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

pgsql-hackers by date

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

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