From: | Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Present all committed transaction to the output plugin |
Date: | 2021-02-21 10:05:34 |
Message-ID: | c4bcbebb-2b35-43fd-7a18-4e620c84676f@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 convinced it's useful.
I don't have any further argument than: If you're promising to replicate
two phases, I expect the first phase to be replicated individually.
A database state with a transaction prepared and identified by
'woohoo-roll-me-back-if-you-can' is not the same as a state without it.
Even if the transaction is empty, or if you're actually going to roll
it back. And therefore possibly ending up at the very same state without
any useful effect.
Regards
Markus
Attachment | Content-Type | Size |
---|---|---|
0001-Present-empty-prepares-to-the-output-plugin.patch | text/x-patch | 4.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Fan | 2021-02-21 10:11:39 | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Previous Message | Paul Guo | 2021-02-21 07:45:43 | Re: Freeze the inserted tuples during CTAS? |