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>, Nisha Moond <nisha.moond412@gmail.com>
Date: 2025-04-22T03:23:36Z
Lists: pgsql-hackers 
On Fri, Apr 18, 2025 at 9:58 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Apr 17, 2025 at 6:14 PM Zhijie Hou (Fujitsu)
> <houzj.fnst@fujitsu.com> wrote:
> >
> > -----
> > 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?
>

Thinking more about this problem, it seems to me that if the
catalog_xmin of synced slot is allowed to be ahead than the
remote_slot when there is still an open (prepared transaction), it
could cause data loss.  I mean that after the promotion, some of the
required catalog rows could be removed, and decoding corresponding
changes (changes from tables affected by DDL) could give unexpected
results. Those would be protected on primary/publisher because the
catalog_xmin on it was still accurate and behind. If this theory turns
out to be true, then this is a drawback/bug of the existing
fast_forward mode code.

-- 
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.