Date: Mon, 19 Jul 2021 23:11:29 +0900
From: Yugo NAGATA <nagata@sraoss.co.jp>
To: Yugo NAGATA <nagata@sraoss.co.jp>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Question about non-blocking mode in libpq
Message-Id: <20210719231129.b2ab655c0d0e80545274c86f@sraoss.co.jp>
In-Reply-To: <20210713115949.702986955f8ccf23fa81073c@sraoss.co.jp>
References: <20210713115949.702986955f8ccf23fa81073c@sraoss.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20210719231129.b2ab655c0d0e80545274c86f%40sraoss.co.jp>
Precedence: bulk

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>