Re: [PATCH] Present all committed transaction to the output plugin

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