Re: Slow catchup of 2PC (twophase) transactions on replica in LR
От | Amit Kapila |
---|---|
Тема | Re: Slow catchup of 2PC (twophase) transactions on replica in LR |
Дата | |
Msg-id | CAA4eK1+n7M2S1OpoGWDd+YZkDCuURMdVRbvP0eELQUvWgmDneg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Slow catchup of 2PC (twophase) transactions on replica in LR (Ajin Cherian <itsajin@gmail.com>) |
Ответы |
Re: Slow catchup of 2PC (twophase) transactions on replica in LR
|
Список | 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 по дате отправления: