MIME-Version: 1.0
References: <8fab8-65d74c80-1-2f28e880@39088166> <CAA4eK1KOs3s6syZqUgrd2WvjTz64SGf0ToZcRoPMCKKH+M0YFQ@mail.gmail.com>
 <99df2-65d8d200-1-63c26880@172687752>
In-Reply-To: <99df2-65d8d200-1-63c26880@172687752>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Mon, 26 Feb 2024 18:54:55 +0530
Message-ID: <CAA4eK1KtjjPxe5tjWeGNf5CfF9qfceVQCCC9XGsKzR-ifQD9uA@mail.gmail.com>
Subject: Re: Slow catchup of 2PC (twophase) transactions on replica in LR
To: =?UTF-8?B?0JTQsNCy0YvQtNC+0LIg0JLQuNGC0LDQu9C40Lk=?= <v.davydov@postgrespro.ru>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAA4eK1KtjjPxe5tjWeGNf5CfF9qfceVQCCC9XGsKzR-ifQD9uA%40mail.gmail.com>
Precedence: bulk

On Fri, Feb 23, 2024 at 10:41=E2=80=AFPM =D0=94=D0=B0=D0=B2=D1=8B=D0=B4=D0=
=BE=D0=B2 =D0=92=D0=B8=D1=82=D0=B0=D0=BB=D0=B8=D0=B9
<v.davydov@postgrespro.ru> wrote:
>
> Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> I don't see we do anything specific for 2PC transactions to make them beh=
ave differently than regular transactions with respect to synchronous_commi=
t setting. What makes you think so? Can you pin point the code you are refe=
rring to?
>
> Yes, sure. The function RecordTransactionCommitPrepared is called on prep=
ared transaction commit (twophase.c). It calls XLogFlush unconditionally. T=
he function RecordTransactionCommit (for regular transactions, xact.c) call=
s XLogFlush if synchronous_commit > OFF, otherwise it calls XLogSetAsyncXac=
tLSN.
>
> There is some comment in RecordTransactionCommitPrepared (by Bruce Momjia=
n) that shows that async commit is not supported yet:
> /*
> * We don't currently try to sleep before flush here ... nor is there any
> * support for async commit of a prepared xact (the very idea is probably
> * a contradiction)
> */
> /* Flush XLOG to disk */
> XLogFlush(recptr);
>

It seems this comment is added in the commit 4a78cdeb where we added
async commit support. I think the reason is probably that when the WAL
record for prepared is already flushed then what will be the idea of
async commit here?

> Right, I think for this we need to implement parallel apply.
>
> Yes, parallel apply is a good point. But, I believe, it will not work if =
asynchronous commit is not supported. You have only one receiver process wh=
ich should dispatch incoming messages to parallel workers. I guess, you wil=
l never reach such rate of parallel execution on replica as on the master w=
ith multiple backends.
>
>
> Can you be a bit more specific about what exactly you have in mind to ach=
ieve the above solutions?
>
> My proposal is to implement async commit for 2PC transactions as it is fo=
r regular transactions. It should significantly speedup the catchup process=
. Then, think how to apply in parallel, which is much diffcult to do. The c=
urrent problem is to get 2PC state from the WAL on commit prepared. At this=
 moment, the WAL is not flushed yet, commit function waits until WAL with 2=
PC state is to be flushed. I just tried to do it in my sandbox and found su=
ch a problem. Inability to get 2PC state from unflushed WAL stops me right =
now. I think about possible solutions.
>

At commit prepared, it seems we read prepare's WAL record, right? If
so, it is not clear to me do you see a problem with a flush of
commit_prepared or reading WAL for prepared or both of these.

--=20
With Regards,
Amit Kapila.