From: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Question about non-blocking mode in libpq |
Date: | 2021-07-21 01:15:09 |
Message-ID: | 20210721101509.7e70e0f801a4457a2f6a6174@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Alvaro,
On Tue, 20 Jul 2021 12:05:11 -0400
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> On 2021-Jul-19, Yugo NAGATA wrote:
>
> > On Tue, 13 Jul 2021 11:59:49 +0900
> > Yugo NAGATA <nagata(at)sraoss(dot)co(dot)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 <nagata(at)sraoss(dot)co(dot)jp>
Attachment | Content-Type | Size |
---|---|---|
fix_doc_libpq_nonblocking.patch | text/x-diff | 741 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2021-07-21 01:15:19 | Re: [PATCH] Use optimized single-datum tuplesort in ExecSort |
Previous Message | David Rowley | 2021-07-21 01:07:35 | Re: [PATCH] Use optimized single-datum tuplesort in ExecSort |