From: "Vitaly Davydov" <v.davydov@postgrespro.ru>
In-Reply-To: <OSBPR01MB2552E1B03A76FE7D2D7CC748F5DF2@OSBPR01MB2552.jpnprd01.prod.outlook.com>
Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_org_NGMime-936352-1720188379.633350-9------"
References: <8fab8-65d74c80-1-2f28e880@39088166>
 <CAA4eK1KOs3s6syZqUgrd2WvjTz64SGf0ToZcRoPMCKKH+M0YFQ@mail.gmail.com>
 <99df2-65d8d200-1-63c26880@172687752>
 <CAA4eK1KtjjPxe5tjWeGNf5CfF9qfceVQCCC9XGsKzR-ifQD9uA@mail.gmail.com>
 <ba4b6-65ddc580-9-5c3e3080@134362348>
 <CAA4eK1J6wOMkDDt3iOs+JqkvQvuwSORosTpqdejgvXqFmxex=A@mail.gmail.com>
 <badcf-65dde500-3-24ba3c80@28790566> <cedbe-65e0c000-1-6db17700@133269862>
 <a375c573-6c9b-4f0f-82c4-eb19cef2a4ca@iki.fi>
 <f9f1b-65e72c80-7-533dda00@76203995>
 <CAFPTHDbU4EkVmKL66i5BzrmQ6LFftQPx_TZ1euKt9fvVzQDyjA@mail.gmail.com>
 <CAA4eK1+n7M2S1OpoGWDd+YZkDCuURMdVRbvP0eELQUvWgmDneg@mail.gmail.com>
 <CAFPTHDa=pJSZ_4dV5DPAOapRSgPcyyUTP0WzGY2Rz_D3-gwraw@mail.gmail.com>
 <CAA4eK1K1fSkeK=kc26G5cq87vQG4=1qs_b+no4+ep654SeBy1w@mail.gmail.com>
 <OSBPR01MB2552707A847936E6803CFAA5F5092@OSBPR01MB2552.jpnprd01.prod.outlook.com>
 <CAA4eK1KY=uwXXuVMtuNTYHGFbbXgDveoFoP3UbxNXqxCAx8GBQ@mail.gmail.com>
 <OSBPR01MB25528F4B0B8178D3AA8DE2BFF5082@OSBPR01MB2552.jpnprd01.prod.outlook.com>
 <CAA4eK1KNrm8xE-ZOAS249m+DOk=YQ_YaoM-GsZEvC8rTMtdW8w@mail.gmail.com>
 <CAFPTHDaz4cyRN3NbjYtkqCKFj7Dv1u0Z8wviY8fnJW4+0CkF_Q@mail.gmail.com>
 <CAFPTHDZNwMWfJZprw9jsoa4-19-h337KRY9Pt41PdNiQTTYaiQ@mail.gmail.com>
 <OSBPR01MB2552083E59F366B465DF0EF8F5122@OSBPR01MB2552.jpnprd01.prod.outlook.com>
 <CAA4eK1Jpj2Ebk2C_9meEDfZKen38cxpzOkxZ7818f1cfsT8=3w@mail.gmail.com>
 <OSBPR01MB2552A7C652D452185785A3C2F5DE2@OSBPR01MB2552.jpnprd01.prod.outlook.com>
 <CAA4eK1LhYsNq_0XKspfWKx4oXZpXk_q-A1Oa-tbA-wqQUudhCQ@mail.gmail.com>
 <OSBPR01MB25527C8A6257443FAE7391C3F5DF2@OSBPR01MB2552.jpnprd01.prod.outlook.com> <OSBPR01MB2552E1B03A76FE7D2D7CC748F5DF2@OSBPR01MB2552.jpnprd01.prod.outlook.com>
Date: Fri, 05 Jul 2024 17:06:19 +0300
Cc: "Amit Kapila" <amit.kapila16@gmail.com>, "Ajin Cherian" <itsajin@gmail.com>, "Heikki Linnakangas" <hlinnaka@iki.fi>, =?utf-8?q?pgsql-hackers=40lists=2Epostgresql=2Eorg?= <pgsql-hackers@lists.postgresql.org>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
MIME-Version: 1.0
Message-ID: <e49a0-6687fe00-33-2d9a93c0@151011886>
Subject: =?utf-8?q?RE=3A?= Slow catchup of 2PC (twophase) transactions on replica in 
 LR
User-Agent: SOGoMail 5.10.0
Archived-At: <https://www.postgresql.org/message-id/e49a0-6687fe00-33-2d9a93c0%40151011886>
Precedence: bulk

------=_=-_OpenGroupware_org_NGMime-936352-1720188379.633350-9------
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Length: 1071


Hi Kuroda-san,

Thank you very much for the patch. In general, it seem to work well for=
 me, but there seems to be a memory access problem in libpqrcv=5Falter=5F=
slot -> quote=5Fidentifier in case of NULL slot=5Fname. It happens, if =
the two=5Fphase option is altered on a subscription without slot. I thi=
nk, a simple check for NULL may fix the problem. I guess, the same prob=
lem may be for failover option.

Another possible problem is related to my use case. I haven't reproduce=
d this case, just some thoughts. I guess, when two=5Fphase is ON, the P=
REPARE statement may be truncated from the WAL at checkpoint, but COMMI=
T PREPARED is still kept in the WAL. On catchup, I would ask the master=
 to send transactions from some restart LSN. I would like to get all su=
ch transactions competely, with theirs bodies, not only COMMIT PREPARED=
 messages. One of the solutions is to have an option for the slot to ke=
ep the WAL like with two=5Fphase =3D OFF independently on its two=5Fpha=
se option. It is just an idea.

With best regards,
Vitaly

------=_=-_OpenGroupware_org_NGMime-936352-1720188379.633350-9------
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Length: 1127

<html>Hi Kuroda-san,<br /><br />Thank you very much for the patch. In g=
eneral, it seem to work well for me, but there seems to be a memory acc=
ess problem in libpqrcv=5Falter=5Fslot -&gt; quote=5Fidentifier in case=
 of NULL slot=5Fname. It happens, if the two=5Fphase option is altered =
on a subscription without slot. I think, a simple check for NULL may fi=
x the problem. I guess, the same problem may be for failover option.<br=
 /><br />Another possible problem is related to my use case. I haven't =
reproduced this case, just some thoughts. I guess, when two=5Fphase is =
ON, the PREPARE statement may be truncated from the WAL at checkpoint, =
but COMMIT PREPARED is still kept in the WAL. On catchup, I would ask t=
he master to send transactions from some restart LSN. I would like to g=
et all such transactions competely, with theirs bodies, not only COMMIT=
 PREPARED messages. One of the solutions is to have an option for the s=
lot to keep the WAL like with two=5Fphase =3D OFF independently on its =
two=5Fphase option. It is just an idea.<br /><br />With best regards,<b=
r />Vitaly</html>

------=_=-_OpenGroupware_org_NGMime-936352-1720188379.633350-9--------