On Tue, 13 Jul 2021 11:59:49 +0900 Yugo NAGATA <nag...@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 <nag...@sraoss.co.jp>
