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 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.
IMHO it's quite weird to handle the 2PC and non-2PC cases differently.
If the argument is that this is expensive, it'd be good to quantify
that, somehow. If there's a workload with significant fraction of such
empty transactions, does that mean +1% CPU usage, +10% or more?
Why not to make this configurable, i.e. the output plugin might indicate
whether it's interested in empty transactions or not. If not, we can do
what we do now. Otherwise the empty transactions would be passed to the
output plugin.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
