On Wed, Aug 16, 2023 at 03:20:53AM +0200, Tomas Vondra wrote: > 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?
Yes, I also think that this is a pretty serious issue to not ensure durability in the non-transactional case if you have solutions designed around that. > 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). I mean, just look at the first message of the thread I am mentioning at the top of this thread: it lists three cases where something like pg_logical_emit_message() was wanted. And, it looks like a serious issue to me for the first two ones at least (out-of-order messages and inter-node communication), because an application may want to send something from node1 to node2, and node1 may just forget about it entirely if it crashes, finishing WAL redo at an earlier point than the record inserted. > 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. Agreed. The original thread never mentions "flush", "sync" or "durab". I won't fight much if there are objections to backpatching, but that's not really wise (no idea how much EDB's close flavor of BDR relies on that). -- Michael
signature.asc
Description: PGP signature