Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ruYl9-0067bj-N9 for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Apr 2024 14:17:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1ruYl8-003FXq-Oa for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Apr 2024 14:17:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ruYl8-003FXh-At for pgsql-hackers@lists.postgresql.org; Wed, 10 Apr 2024 14:17:06 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ruYl5-002Bvv-4P for pgsql-hackers@lists.postgresql.org; Wed, 10 Apr 2024 14:17:05 +0000 Received: from sogo.postgrespro.ru (unknown [192.168.2.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix/587) with ESMTPS id 2FAC2E20EEE; Wed, 10 Apr 2024 17:16:59 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1712758619; bh=qOclL3ROJYSi+pLiaguVNIfEO0DF+QvHuBFteFxqDD0=; h=From:In-Reply-To:References:Date:Cc:To:Message-ID:Subject: User-Agent:From; b=eUNSPD9Gzvn8pR5+pb7utIrPznHgbvoxLGeKZe77uukcs+gba2mvB/nvhaEkycstj eN9ER3pA6Gv4kSFYrhSjq1FF8OtWlOnxKij8/NiMnv/fPbW3ktcXmNoWUtqRD7IyzV O6w0/85q5YHYfzIhlQHcWF9E60REIKSDLwxXbztjvvsxMMvM+tKofSgKT2TdqDz5mP 1BXsB/gh6Kgebsi22QfQqmtLcVdmXx9mwcF2MdYRr/dNwr7ErbvD98GbtpixCaaaaS Ktw1g3Eqm+slnZDCg3dPvL6j4RHhKcrK4W3MqT5ZaZ6ap74jMn09v+rOqNvxp+B9HF 384KhL5Tcd2xQ== From: =?utf-8?q?=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?= In-Reply-To: Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_org_NGMime-2347466-1712758619.057866-11------" X-Forward: 93.174.131.141 References: <8fab8-65d74c80-1-2f28e880@39088166> <99df2-65d8d200-1-63c26880@172687752> Date: Wed, 10 Apr 2024 17:16:59 +0300 Cc: "Ajin Cherian" , "Heikki Linnakangas" , pgsql-hackers@lists.postgresql.org To: "Amit Kapila" MIME-Version: 1.0 Message-ID: <23d1ca-66169f80-1f-5a90aa00@207285398> Subject: =?utf-8?q?Re=3A?= Slow catchup of 2PC (twophase) transactions on replica in LR User-Agent: SOGoMail 5.10.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_=-_OpenGroupware_org_NGMime-2347466-1712758619.057866-11------ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 1178 Hi Amit, Ajin, All Thank you for the patch and the responses. I apologize for my delayed a= nswer due to some=C2=A0curcumstances. On Wednesday, April 10, 2024 14:18 MSK, Amit Kapila wrote: Vitaly, does the minimal solution provided by the proposed patch (Allow= to alter two=5Fphase option of a subscriber provided no uncommitted pr= epared transactions are pending on that subscription.) address your use= case?In general, the idea behind the patch seems to be suitable for my= case. Furthermore, the case of two=5Fphase switch from false to true w= ith uncommitted pending prepared transactions probably never happens in= my case. The switch from false to true means that the replica complete= s the catchup from the master and switches to the normal mode when it p= articipates in the multi-node configuration. There should be no uncommi= tted pending prepared transactions at the moment of the switch to the n= ormal mode. I'm going to try this patch. Give me please some time to investigate th= e patch. I will come with some feedback a little bit later. Thank you for your help! With best regards, Vitaly Davydov =C2=A0 ------=_=-_OpenGroupware_org_NGMime-2347466-1712758619.057866-11------ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 1309 Hi Amit, Ajin, All

Thank you for the patch and the res= ponses. I apologize for my delayed answer due to some curcumstance= s.

On Wednesday, April 10, 2024 14:18 MSK, Amit Kapila &l= t;amit.kapila16@gmail.com> wrote:

Vitaly, does the minima= l solution provided by the proposed patch (Allow to alter two=5Fphase o= ption of a subscriber provided no uncommitted prepared transactions are= pending on that subscription.) address your use case?

= In general, the idea behind the patch seems to be suitable for my case.= Furthermore, the case of two=5Fphase switch from false to true with un= committed pending prepared transactions probably never happens in my ca= se. The switch from false to true means that the replica completes the = catchup from the master and switches to the normal mode when it partici= pates in the multi-node configuration. There should be no uncommitted p= ending prepared transactions at the moment of the switch to the normal = mode.

I'm going to try this patch. Give me please some time = to investigate the patch. I will come with some feedback a little bit l= ater.

Thank you for your help!

With best regards,=
Vitaly Davydov


  ------=_=-_OpenGroupware_org_NGMime-2347466-1712758619.057866-11--------