Hello,
On 28/04/2023 13:06, Robert Haas wrote:
On Fri, Mar 24, 2023 at 6:39 PM Anton Kirilov <antonvkiri...@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
