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>
