Re: pg_logical_emit_message() misses a XLogFlush()

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: pg_logical_emit_message() misses a XLogFlush()
Дата
Msg-id 619e219c-5894-cfd0-5634-0d465c41130b@enterprisedb.com
обсуждение исходный текст
Ответ на Re: pg_logical_emit_message() misses a XLogFlush()  (Andres Freund <andres@anarazel.de>)
Ответы Re: pg_logical_emit_message() misses a XLogFlush()  (Michael Paquier <michael@paquier.xyz>)
Re: pg_logical_emit_message() misses a XLogFlush()  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 8/16/23 02:33, Andres Freund wrote:
> Hi,
> 
> On 2023-08-16 06:58:56 +0900, Michael Paquier wrote:
>> On Tue, Aug 15, 2023 at 11:37:32AM +0200, Tomas Vondra wrote:
>>> Shouldn't the flush be done only for non-transactional messages? The
>>> transactional case will be flushed by regular commit flush.
>>
>> Indeed, that would be better.  I am sending an updated patch.
>>
>> I'd like to backpatch that, would there be any objections to that?
> 
> Yes, I object. This would completely cripple the performance of some uses of
> logical messages - a slowdown of several orders of magnitude. It's not clear
> to me that flushing would be the right behaviour if it weren't released, but
> it certainly doesn't seem right to make such a change in a minor release.
> 

So are you objecting to adding the flush in general, or just to the
backpatching part?

IMHO we either guarantee durability of non-transactional messages, in
which case this would be a clear bug - and I'd say a fairly serious one.
I'm curious what the workload that'd see order of magnitude of slowdown
does with logical messages, but even if such workload exists, would it
really be enough to fix any other durability bug?

Or perhaps we don't want to guarantee durability for such messages, in
which case we don't need to fix it at all (even in master).

The docs are not very clear on what to expect, unfortunately. It says
that non-transactional messages are "written immediately" which I could
interpret in either way.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Richard Guo
Дата:
Сообщение: Re: Test case for parameterized remote path in postgres_fdw
Следующее
От: "Hayato Kuroda (Fujitsu)"
Дата:
Сообщение: RE: [PoC] pg_upgrade: allow to upgrade publisher node