Date: Tue, 20 Jul 2021 12:05:11 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Yugo NAGATA <nagata@sraoss.co.jp>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Question about non-blocking mode in libpq
Message-ID: <202107201605.b3hmz4g6uqqz@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210719231129.b2ab655c0d0e80545274c86f@sraoss.co.jp>
Archived-At: 
 <https://www.postgresql.org/message-id/202107201605.b3hmz4g6uqqz%40alvherre.pgsql>
Precedence: bulk

On 2021-Jul-19, Yugo NAGATA wrote:

> On Tue, 13 Jul 2021 11:59:49 +0900
> Yugo NAGATA <nagata@sraoss.co.jp> wrote:

> > However, looking into the code, PQsendQuery seems not to return an error
> > in non-bloking mode even if unable to send all data. In such cases,
> > pqSendSome will return 1 but it doesn't cause an error. Moreover,
> > we would not need to call PQsendQuery again. Indead, we need to call
> > PQflush until it returns 0, as documented with regard to PQflush.
> > 
> > Do we need to fix the description of PQsetnonblocking?

Yeah, I think you're right -- these functions don't error out, the
commands are just stored locally in the output buffer.

>  "In the nonblocking state, calls to PQsendQuery, PQputline, PQputnbytes,
>  PQputCopyData, and PQendcopy will not block" 
> 
> this seems to me that this is a list of functions that could block in blocking
> mode, but I wander PQflush also could block because it calls pqSendSome, right?

I don't see that.  If pqSendSome can't write anything, it'll just return 1.

> Also, in the last paragraph of the section, I can find the following:
> 
>  "After sending any command or data on a nonblocking connection, call PQflush. ..."
> 
> However, ISTM we don't need to call PQflush in non-bloking mode and we can
> call PQgetResult immediately because PQgetResult internally calls pqFlush
> until it returns 0 (or -1).

Well, maybe you don't *need* to PQflush(); but if you don't call it,
then the commands will sit in the output buffer indefinitely, which
means the server won't execute them.  So even if it works to just call
PQgetResult and have it block, surely you would like to only call
PQgetResult when the query has already been executed and the result
already been received and processed; that is, so that you can call
PQgetResult and obtain the result immediately, and avoid (say) blocking
a GUI interface while PQgetResult flushes the commands out, the server
executes the query and sends the results back.

> Therefore, I wander the last paragraph of this section is
> now unnecessary. right?

Doesn't seem so to me.

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/