| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_logical_emit_message() misses a XLogFlush() |
| Date: | 2023-08-16 07:51:53 |
| Message-ID: | ZNyAGSL1D6VKmGvq@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Aug 15, 2023 at 09:16:53PM -0700, Andres Freund wrote:
> To be clear: I don't just object to backpatching, I also object to making
> existing invocations flush WAL in HEAD. I do not at all object to adding a
> parameter that indicates flushing, or a separate function to do so. The latter
> might be better, because it allows you to flush a group of messages, rather
> than a single one.
For the latter, am I getting it right that you mean a function
completely outside of the scope of LogLogicalMessage() and
pg_logical_emit_message()? Say, a single pg_wal_flush(lsn)?
I am a bit concerned by that, because anybody calling directly
LogLogicalMessage() or the existing function would never really think
about durability but they may want to ensure a message flush in their
code calling it. Adding an argument does not do much about the SQL
function if it has a DEFAULT, still it addresses my first concern
about the C part.
Anyway, attached is a patch to add a 4th argument "flush" that
defaults to false. Thoughts about this version are welcome.
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0001-Add-flush-argument-to-pg_logical_emit_message.patch | text/x-diff | 8.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-08-16 08:02:09 | Re: Return value of pg_promote() |
| Previous Message | Zhang Mingli | 2023-08-16 07:34:56 | Fix typo in src/interfaces/libpq/po/zh_CN.po |