Hi, On 2021-02-20 21:44:30 +0100, Markus Wanner wrote: > On 20.02.21 21:08, Andres Freund wrote: > > It's not free though > > Agreed. It's an additional call to a callback.
If it were just a single indirection function call I'd not be bothered. But we need to do a fair bit mroe than that (c.f. ReorderBufferProcessTXN()). > Do you think that's acceptable if limited to two-phase transactions > only? Cost-wise, yes - a 2pc prepare/commit is expensive enough that comparatively the replay cost is unlikely to be relevant. Behaviourally I'm still not convinced it's useful. > > I'm wondering the opposite: What's a potential use case for handing > > "trivially empty" transactions to the output plugin that's worth > > incurring some cost for everyone? > > Outlined in my previous mail: prepare the transaction on one node, commit it > on another one. The PREPARE of a transaction is an event a user may well > want to have replicated, without having to worry about whether or not the > transaction happens to be empty. I read the previous mails in this thread, and I don't really see an explanation for why this is something actually useful. When is a transaction without actual contents interesting to replicate? I don't find the "gid potentially carries information" particularly convincing. > [ Imagine: ERROR: transaction cannot be replicated because it's empty. > HINT: add a dummy UPDATE so that Postgres always has > something to replicate, whatever else your app does > or does not do in the transaction. ] Meh. Greetings, Andres Freund
