Hello Alvaro, On Tue, 20 Jul 2021 12:05:11 -0400 Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
> On 2021-Jul-19, Yugo NAGATA wrote: > > > On Tue, 13 Jul 2021 11:59:49 +0900 > > Yugo NAGATA <nag...@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. Thank you for your explanation! I attached a patch fix the description. > > "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. Well, is this the case of non-blocking mode, nor? If I understood correctly, pqSendSome could block in blocking mode, so PQflush could block, too. I thought we should add PQflush to the list in the description to enphasis that this would not block in non-blocking mode. However, now I don't think so because PQflush seems useful only in non-blocking mode. > > 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. I understood that, although PQgetResult() also flushes the buffer, we still should call PQflush() beforehand because we would not like get blocked after calling PQgetResult(). Thanks. Regards, Yugo Nagata -- Yugo NAGATA <nag...@sraoss.co.jp>
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 56689ba873..03ac480d0c 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -4924,8 +4924,8 @@ int PQsetnonblocking(PGconn *conn, int arg); In the nonblocking state, calls to <xref linkend="libpq-PQsendQuery"/>, <xref linkend="libpq-PQputline"/>, <xref linkend="libpq-PQputnbytes"/>, <xref linkend="libpq-PQputCopyData"/>, - and <xref linkend="libpq-PQendcopy"/> will not block but instead return - an error if they need to be called again. + and <xref linkend="libpq-PQendcopy"/> will not block but the commands are + stored locally in the output buffer until it is flushed. </para> <para>