Re: Slow catchup of 2PC (twophase) transactions on replica in LR - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Slow catchup of 2PC (twophase) transactions on replica in LR
Date
Msg-id CAA4eK1+n7M2S1OpoGWDd+YZkDCuURMdVRbvP0eELQUvWgmDneg@mail.gmail.com
Whole thread Raw
In response to Re: Slow catchup of 2PC (twophase) transactions on replica in LR  (Ajin Cherian <itsajin@gmail.com>)
Responses Re: Slow catchup of 2PC (twophase) transactions on replica in LR
List pgsql-hackers
On Thu, Apr 4, 2024 at 10:53 AM Ajin Cherian <itsajin@gmail.com> wrote:
>
> On Wed, Mar 6, 2024 at 1:29 AM Давыдов Виталий <v.davydov@postgrespro.ru> wrote:
>>
>> In usual work, the subscription has two_phase = on. I have to change this option at catchup stage only, but this
parametercan not be altered. There was a patch proposal in past to implement altering of two_phase option, but it was
rejected.I think, the recreation of the subscription with two_phase = off will not work. 
>>
>>
>
> The altering of two_phase was restricted because if there was a previously prepared transaction on the subscriber
whenthe two_phase was on, and then it was turned off, the apply worker on the subscriber would re-apply the transaction
asecond time and this might result in an inconsistent replica. 
> Here's a patch that allows toggling two_phase option provided that there are no pending uncommitted prepared
transactionson the subscriber for that subscription. 
>

I think this would probably be better than the current situation but
can we think of a solution to allow toggling the value of two_phase
even when prepared transactions are present? Can you please summarize
the reason for the problems in doing that and the solutions, if any?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Fix for timestamp lag issue from emit_log_hook when GUC log_line_prefix has '%m'
Next
From: Bharath Rupireddy
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation