On Mon, Apr 28, 2025 at 2:27 PM Zhijie Hou (Fujitsu) <houzj.f...@fujitsu.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.f...@fujitsu.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
