Re: Slow catchup of 2PC (twophase) transactions on replica in LR

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Давыдов Виталий <v(dot)davydov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Slow catchup of 2PC (twophase) transactions on replica in LR
Date: 2024-03-05 09:05:40
Message-ID: a375c573-6c9b-4f0f-82c4-eb19cef2a4ca@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29/02/2024 19:34, Давыдов Виталий wrote:
> Dear All,
>
> Consider, please, my patch for async commit for twophase transactions.
> It can be applicable when catchup performance is not enought with
> publication parameter twophase = on.
>
> The key changes are:
>
> * Use XLogSetAsyncXactLSN instead of XLogFlush as it is for usual
> transactions.
> * In case of async commit only, save 2PC state in the pg_twophase file
> (but not fsync it) in addition to saving in the WAL. The file is
> used as an alternative to storing 2pc state in the memory.
> * On recovery, reject pg_twophase files with future xids.
>
> Probably, 2PC async commit should be enabled by a GUC (not implemented
> in the patch).

In a nutshell, this changes PREPARE TRANSACTION so that if
synchronous_commit is 'off', the PREPARE TRANSACTION is not fsync'd to
disk. So if you crash after the PREPARE TRANSACTION has returned, the
transaction might be lost. I think that's completely unacceptable.

If you're ok to lose the prepared state of twophase transactions on
crash, why don't you create the subscription with 'two_phase=off' to
begin with?

--
Heikki Linnakangas
Neon (https://neon.tech)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2024-03-05 09:36:29 Re: "type with xxxx does not exist" when doing ExecMemoize()
Previous Message Nikita Malakhov 2024-03-05 09:03:35 Re: Shared detoast Datum proposal