Hello,
On 28/04/2023 13:06, Robert Haas wrote:
> On Fri, Mar 24, 2023 at 6:39 PM Anton Kirilov <antonvkirilov@gmail.com> wrote:
>> I have attached a patch that introduces PQsendSyncMessage()...
>
> I wonder whether this is the naming that we want. The two names are
> significantly different. Something like PQpipelineSendSync() would be
> more similar.
The reason is that the function is modeled after PQsendFlushRequest(),
since it felt closer to what I was trying to achieve, i.e. appending a
protocol message to the output buffer without doing any actual I/O
operations.
> I also wonder, really even more, whether it would be better to do
> something like PQpipelinePutSync(PGconn *conn, bool flush) with
> PQpipelineSync(conn) just meaning PQpipelinePutSync(conn, true).
Actually I believe that there is another issue with PQpipelineSync()
that has to do with ergonomics - according to a comment inside its body
(
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/interfaces/libpq/fe-exec.c;h=a16bbf32ef5c0043eee9c92ab82bf4f11386ee47;hb=HEAD#l3189
) it could fail silently to send all the buffered data, which seems to
be problematic when operating in non-blocking mode. In practice, this
means that all calls to PQpipelineSync() must be followed by execution
of PQflush() to check whether the application should poll for write
readiness. I suppose that that was the reason why I was going for a
solution that did not combine changing the connection state with doing
I/O operations.
In any case I am not particularly attached to any naming or the exact
shape of the new API, as long as it achieves the same goal (reducing the
number of system calls), but before I make any substantial changes to my
patch, I would like to hear your thoughts on the matter.
Best wishes,
Anton Kirilov