Re: pg_logical_emit_message() misses a XLogFlush()

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_logical_emit_message() misses a XLogFlush()
Дата
Msg-id ZNyAGSL1D6VKmGvq@paquier.xyz
обсуждение исходный текст
Ответ на Re: pg_logical_emit_message() misses a XLogFlush()  (Andres Freund <andres@anarazel.de>)
Ответы Re: pg_logical_emit_message() misses a XLogFlush()  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zhang Mingli
Дата:
Сообщение: Fix typo in src/interfaces/libpq/po/zh_CN.po
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Return value of pg_promote()