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

Hi,

On Fri, Nov 13, 2026 at 04:45:00PM +0530, Amit Kapila wrote:
> On Wed, Nov 11, 2026 at 8:43 PM Zhijie Hou <houzhijie22(at)gmail(dot)com> wrote:
> >
> > On Wed, Nov11, 2026 at 01:04 AM Bertrand Drouvot wrote:
> >
> > > On Tue, Nov 10, 2026 at 05:17:57PM +0800, Zhijie Hou wrote:
> >
> > Thanks for catching this. I confirmed that this can happen.
> >
> > 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.
> >
>
> + else if (slot->data.persistency == RS_TEMPORARY)
> + {
> + /*
> + * We reach this point when a previous cycle updated confirmed_flush
> + * but failed to build a consistent snapshot, and the remote slot has
> + * not advanced beyond the local slot since then.
> + */
> + skip_reason = SS_SKIP_NO_CONSISTENT_SNAPSHOT;
> + }
>
> Is it better to directly use the slot's skip_reason rather than
> assuming SS_SKIP_NO_CONSISTENT_SNAPSHOT?

That could work but what about the case I mentioned upthread where the local
catalog_xmin gets ahead and the remote later catches up? I think that that would
keep slotsync_skip_reason as SS_SKIP_WAL_OR_ROWS_REMOVED, although the slot is
still inconsistent due to the missing snapshot.

> I understand today it is correct but tomorrow if there are more reasons

Maybe we could keep v2 and assert the two possible previous reasons, so any new
reason would need explicit handling?

Regards,

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