Re: Assertion failure in update_local_synced_slot(), slotsync.c:364

Hi,

On Wed, Nov 11, 2026 at 11:13:13PM +0800, Zhijie Hou wrote:
> Hi,
>
> On Wed, Nov11, 2026 at 01:04 AM Bertrand Drouvot wrote:
>
> > On Tue, Nov 10, 2026 at 05:17:57PM +0800, Zhijie Hou wrote:
> > > I agree with your analysis, and I think we can fix it by preserving
> > > SS_SKIP_NO_CONSISTENT_SNAPSHOT in update_local_synced_slot() when
> > > the remote slot has not advanced since a previous cycle failed to
> > > build a consistent snapshot.
> > >
> > > Attached is a patch for the fix. I also tried to simplify and
> > > stabilize the test and merged it into
> > > 040_standby_failover_slots_sync.pl in case we want to include a
> > > test.
> >
> > Thanks for the patch!
> >
> > + else if (slot->slotsync_skip_reason == SS_SKIP_NO_CONSISTENT_SNAPSHOT)
> >
> > Could slotsync_skip_reason be SS_SKIP_WAL_OR_ROWS_REMOVED here even if
> > the slot is still inconsistent? This could happen if the local
> > catalog_xmin gets ahead and the remote one later catches up?
>
> Thanks for catching this. I confirmed that this can happen.

Thanks for confirming!

> Since any temporary slot that reaches a consistent snapshot is persisted
> immediately in the same cycle, we can check "else if (slot->data.persistency
> == RS_TEMPORARY)" here instead. Attached is the v2 patch with this change.

Thanks for the patch!

Makes sense and LGTM. FWIW, v2 does not test the rare state transition we just
talked about but I don't think it's worth the extra complexity.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com