From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Anton Kirilov <antonvkirilov(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add PQsendSyncMessage() to libpq |
Date: | 2023-05-04 10:36:42 |
Message-ID: | 20230504103642.sip34d7kszi6b4cd@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2023-May-04, Anton Kirilov wrote:
> Thank you all for the feedback! Do you have any thoughts on the other
> issue with PQpipelineSync() I have mentioned in my previous message?
Eh, I hadn't seen that one.
> Am I just misunderstanding what the code comment means and how the API
> is supposed to be used by any chance?
I think you have it right: it is possible that the buffer has not been
fully flushed by the time PQpipelineSync returns.
If you want to make sure it's fully flushed, your only option is to have
the call block. That would make it no longer non-blocking, so it has to
be explicitly requested behavior.
I think this means to add yet another behavior flag for the new
function: have it block, waiting for the buffer to be flushed.
So your application can put several sync points in the queue, with no
flushing (and of course no blocking), and have it flush+block only on
the "last" one. Of course, for other users, you want the current
behavior: have it flush opportunistically but not block. So you can't
make it a single flag.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2023-05-04 10:44:01 | Re: "variable not found in subplan target list" |
Previous Message | Anton Kirilov | 2023-05-04 09:21:56 | Re: Add PQsendSyncMessage() to libpq |