Re: Question about non-blocking mode in libpq

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

> Hello,
> 
> During reading the documentation of libpq [1] , I found the following
> description:
> 
>  In the nonblocking state, calls to PQsendQuery, PQputline, PQputnbytes,
>  PQputCopyData, and PQendcopy will not block but instead return an error
>  if they need to be called again.
> 
> [1] https://www.postgresql.org/docs/devel/libpq-async.html
> 
> 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?

I have further questions. Reading the following statement:

 "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?

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).

        /*
         * If data remains unsent, send it.  Else we might be waiting for the
         * result of a command the backend hasn't even got yet.
         */
        while ((flushResult = pqFlush(conn)) > 0) 
        {
            if (pqWait(false, true, conn))
            {
                flushResult = -1;
                break;
            }
        }

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

-- 
Yugo NAGATA <nagata@sraoss.co.jp>