| From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz>, 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-09-11 03:54:11 |
| Message-ID: | c16e16ac-a6e7-6c10-894f-e95ecfbde9ad@oss.nttdata.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2023/08/16 16:51, Michael Paquier wrote:
> Anyway, attached is a patch to add a 4th argument "flush" that
> defaults to false. Thoughts about this version are welcome.
When the "transactional" option is set to true, WAL including
the record generated by the pg_logical_emit_message() function is flushed
at the end of the transaction based on the synchronous_commit setting.
However, in the current patch, if "transactional" is set to false and
"flush" is true, the function flushes the WAL immediately without
considering synchronous_commit. Is this the intended behavior?
I'm not sure how the function should work in this case, though.
Though I don't understand the purpose of this option fully yet,
is flushing the WAL sufficient? Are there scenarios where the function
should ensure that the WAL is not only flushed but also replicated
to the standby?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shveta malik | 2023-09-11 04:19:00 | Re: Synchronizing slots from primary to standby |
| Previous Message | Dilip Kumar | 2023-09-11 03:49:59 | Re: Impact of checkpointer during pg_upgrade |