On 2/21/21 11:05 AM, Markus Wanner wrote:
On 21.02.21 03:04, Andres Freund wrote:
Cost-wise, yes - a 2pc prepare/commit is expensive enough that
comparatively the replay cost is unlikely to be relevant.
Good. I attached an updated patch eliminating only the filtering for
empty two-phase t
On 21.02.21 03:04, Andres Freund wrote:
Cost-wise, yes - a 2pc prepare/commit is expensive enough that
comparatively the replay cost is unlikely to be relevant.
Good. I attached an updated patch eliminating only the filtering for
empty two-phase transactions.
Behaviourally I'm still not co
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.
On 20.02.21 21:08, Andres Freund wrote:
It's not free though
Agreed. It's an additional call to a callback. Do you think that's
acceptable if limited to two-phase transactions only?
I'm wondering the opposite: What's a potential use case for handing
"trivially empty" transactions to the o
Hi,
On 2021-02-20 13:48:49 +0100, Markus Wanner wrote:
> However, that's not what the patch changes. It just moves the decision to
> the output plugin, giving it more flexibility. And possibly allowing it to
> still take action.
It's not free though - there's plenty workloads where there's an x
On 20.02.21 12:15, Amit Kapila wrote:
What exactly is the use case to send empty transactions with or
without prepared?
I'm not saying that output plugins should *send* empty transactions to
the replica. I rather agree that this indeed is not wanted in most cases.
However, that's not what t
On Fri, Feb 19, 2021 at 6:06 PM Markus Wanner
wrote:
>
> Hi,
>
> attached is a patch that I think is cleaning up the API between Postgres
> and the logical decoding plugin. Up until now, not only transactions
> rolled back, but also some committed transactions were filtered and not
> presented to
Hi,
attached is a patch that I think is cleaning up the API between Postgres
and the logical decoding plugin. Up until now, not only transactions
rolled back, but also some committed transactions were filtered and not
presented to the output plugin. While it is documented that aborted
trans