Re: Fix slot synchronization with two_phase decoding enabled

On Mon, Apr 28, 2025 at 2:27 PM Zhijie Hou (Fujitsu)
<houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> On Fri, Apr 18, 2025 at 12:29 PM Amit Kapila wrote:
> >
> > On Thu, Apr 17, 2025 at 6:14 PM Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com>
> > >
> > > -----
> > > Fix
> > > -----
> > >
> > > I think we should keep the confirmed_flush even if the previous synced
> > > restart_lsn/catalog_xmin is newer. Attachments include a patch for the
> > same.
> > >
> >
> > This will fix the case we are facing but adds a new rule for slot synchronization.
> > Can we think of a simpler way to fix this by avoiding updating other slot fields
> > (like two_phase, two_phase_at) if restart_lsn or catalog_xmin of the local slot
> > is ahead of the remote slot?
>
> Since the fix for xmin advancement during fast-forward decoding has been pushed
> (commit aaf9e95), I'm attaching the V2 patch to address the assert failure by
> avoiding updating other slot fields (like two_phase, two_phase_at) if
> restart_lsn or catalog_xmin of the local slot is ahead.
>

The patch looks good to me. We can have minor comment tweak:

+ * Syncing only two_phase_at, without also syncing the latest
+ * confirmed_lsn, might lead to transactions between the old
+ * confirmed_lsn and two_phase_at being unexpectedly decoded and sent
+ * to the subscriber.

We can append "following a promotion".

thanks
Shveta