| From: | Anton Kirilov <antonvkirilov(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| 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-05 15:02:24 |
| Message-ID: | 0F969A73-6C80-4C16-B326-B9E65C3C67E4@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello,
On Thu, 4 May 2023, 11:36 Alvaro Herrera, <alvherre(at)alvh(dot)no-ip(dot)org <mailto:alvherre(at)alvh(dot)no-ip(dot)org>> wrote:
> On 2023-May-04, Anton Kirilov wrote:
> If you want to make sure it's fully flushed, your only option is to have
> the call block.
Surely PQflush() returning 0 would signify that the output buffer has been fully flushed? Which means that there is another, IMHO simpler option than introducing an extra flag - make the new function return the same values as PQflush(), i.e. 0 for no error and fully flushed output, -1 for error, and 1 for partial flush (so that the user may start polling for write readiness). Of course, the function would never return 1 (but would block instead) unless the user has called PQsetnonblocking() beforehand.
Best wishes,
Anton Kirilov
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2023-05-05 16:21:30 | Re: MERGE lacks ruleutils.c decompiling support!? |
| Previous Message | Drouvot, Bertrand | 2023-05-05 14:23:31 | Re: Add two missing tests in 035_standby_logical_decoding.pl |