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

Hi,

On Tue, Nov10, 2026 at 04:04 AM Masahiko Sawada wrote:
> Hi all,
>
> While reviewing slotsync.c, I hit the assertion failure:
>
> TRAP: failed Assert("MyReplicationSlot->data.persistency ==
> RS_TEMPORARY"), slotsync.c:364
>
> IIUC this is a regression of commit 788ec96d591 (CC'ed Hou and Amit).
> In update_local_synced_slot(), we try to advance the local slot only
> when the remote slot is ahead of it, and if the standby cannot reach a
> consistent snapshot we set the skip reason to
> SS_SKIP_NO_CONSISTENT_SNAPSHOT so that
> update_and_persist_local_synced_slot() doesn't persist the slot.
> However, LogicalSlotAdvanceAndCheckSnapState() has already advanced
> confirmed_flush_lsn to the remote's value in that case (restart_lsn
> and catalog_xmin were already equal to the remote's when the slot was
> created). So in the next cycle the remote slot is no longer ahead, we
> skip the advance entirely, and update_slotsync_skip_stats() overwrites
> the skip reason with SS_SKIP_NONE.
> update_and_persist_local_synced_slot() then persists the slot and
> reports it as sync-ready even though nothing has changed since the
> previous cycle. Once the remote slot advances again and the standby
> still cannot find a consistent snapshot, the assertion above fails.
>
> On non-assert builds, IIUC the problem is worse: the persisted slot
> can be used after promotion, and decoding from it skips the
> transactions between its restart_lsn and the first consistent point,
> causing data loss.
>
> Before that commit, update_and_persist_local_synced_slot() also
> checked found_consistent_snapshot returned by
> update_local_synced_slot() for the current cycle, so a cycle that
> didn't attempt to advance the slot never persisted it.
>
> I've attached a TAP test to reproduce this issue, generated by AI.

Thanks for reporting the issue.

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.

--
Best Regards,
Zhijie Hou