Re: Fix slot synchronization with two_phase decoding enabled
От | Masahiko Sawada |
---|---|
Тема | Re: Fix slot synchronization with two_phase decoding enabled |
Дата | |
Msg-id | CAD21AoAbaAf+RsGpts9ysxbagkPfzd_fGD81a3J7u5uAd4LbPQ@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Fix slot synchronization with two_phase decoding enabled ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
Ответы |
RE: Fix slot synchronization with two_phase decoding enabled
|
Список | pgsql-hackers |
On Tue, Apr 8, 2025 at 10:14 PM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote: > > > ---------- > Approach 2 > ---------- > > Instead of disallowing the use of two-phase and failover together, a more > flexible strategy could be only restrict failover for slots with two-phase > enabled when there's a possibility of existing prepared transactions before the > two_phase_at that are not yet replicated. During slot creation with two-phase > and failover, we could check for any decoded prepared transactions when > determining the decoding start point (DecodingContextFindStartpoint). For > subsequent attempts to alter failover to true, we ensure that two_phase_at is > less than restart_lsn, indicating that all prepared transactions have been > committed and replicated, thus the bug would not happen. > > pros: > > This method minimizes restrictions for users. Especially during slot creation > with (two_phase=on, failover=on), as it’s uncommon for transactions to prepare > during consistent snapshot creation, the restriction becomes almost > unnoticeable. I think this approach can work for the transactions that are prepared while the slot is created. But if I understand the problem correctly, while the initial table sync is performing, the slot's two_phase is still false, so we need to deal with the transactions that are prepared during the initial table sync too. What do you think? Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: