From: | Anton Kirilov <antonvkirilov(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add PQsendSyncMessage() to libpq |
Date: | 2023-04-29 16:06:03 |
Message-ID: | ef6bac7d-8d6b-a8e6-579f-f3e026712aeb@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
On 28/04/2023 13:06, Robert Haas wrote:
> On Fri, Mar 24, 2023 at 6:39 PM Anton Kirilov <antonvkirilov(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-04-29 21:14:35 | Re: [PATCH] Clarify the behavior of the system when approaching XID wraparound |
Previous Message | Kim Johan Andersson | 2023-04-29 15:07:19 | [PATCH] Add support function for containment operators |