Horton

Re: Fix slot synchronization with two_phase decoding enabled

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-04-03T02:57:56Z
Lists: pgsql-hackers 
On Thu, Apr 3, 2025 at 7:50 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Thu, Apr 3, 2025 at 3:30 AM Masahiko Sawada wrote:
>
> >
> > On Wed, Apr 2, 2025 at 6:33 AM Zhijie Hou (Fujitsu)
> > <houzj.fnst@fujitsu.com> wrote:
> >
> > Thank you for the explanation! I agree that the issue happens in these cases.
> >
> > As another idea, I wonder if we could somehow defer to make the synced
> > slot as 'sync-ready' until we can ensure that the slot doesn't have
> > any transactions that are prepared before the point of enabling
> > two_phase. For example, when the slotsync worker fetches the remote
> > slot, it remembers the confirmed_flush_lsn (say LSN-1) if the local
> > slot's two_phase becomes true or the local slot is newly created with
> > enabling two_phase, and then it makes the slot 'sync-ready' once it
> > confirmed that the slot's restart_lsn passed LSN-1. Does it work?
>
> Thanks for the idea!
>
> We considered a similar approach in [1] to confirm there is no prepared
> transactions before two_phase_at, but the issue is that when the two_phase flag
> is switched from 'false' to 'true' (as in the case with (copy_data=true,
> failover=true, two_phase=true)). In this case, the slot may have already been
> marked as sync-ready before the two_phase flag is enabled, as slotsync is
> unaware of potential future changes to the two_phase flag.
>

This can happen because when copy_data is true, tablesync can take a
long time to complete the sync and in the meantime, slot without a
two_phase flag would have been synced to standby. Such a slot would be
marked as sync-ready even if we follow the calculation proposed by
Sawada-san. Note that we enable two_phase once all the tables are in
ready state (See run_apply_worker() and comments atop worker.c
(TWO_PHASE TRANSACTIONS)).

-- 
With Regards,
Amit Kapila.

Commits

  1. Don't retreat slot's confirmed_flush LSN.

  2. Fix assertion failure during decoding from synced slots.

  3. Fix xmin advancement during fast_forward decoding.

  4. Fix slot synchronization for two_phase enabled slots.

  5. Again match pg_user_mappings to information_schema.user_mapping_options.