Re: Assertion failure in SnapBuildInitialSnapshot()

On Thu, Nov 6, 2025 at 12:03 PM Zhijie Hou (Fujitsu)
<houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> On Thursday, October 30, 2025 7:01 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> >
> > Also, I think it's worth considering the idea Robert shared before[1]:
> >
> > ---
> > But what about just surgically preventing that?
> > ProcArraySetReplicationSlotXmin() could refuse to retreat the values,
> > perhaps? If it computes an older value than what's there, it just does nothing?
> > ---
> >
> > We did a similar fix for confirmed_flush LSN by commit ad5eaf390c582, and it
> > sounds reasonable to me that ProcArraySetReplicationSlotXmin() refuses to
> > retreat the values.
>
> I reviewed the thread and think that we could not straightforwardly apply a
> similar strategy to prevent the retreat of xmin/catalog_xmin here. This is
> because we maintain a central value
> (replication_slot_xmin/replication_slot_catalog_xmin) in
> ProcArraySetReplicationSlotXmin, where the value is expected to decrease when
> certain slots are dropped or invalidated.
>

Good point. This can happen when the last slot is invalidated or dropped.

>
Therefore, I think we might need to
> continue with the original proposal to invert the lock and also address the code
> path for slotsync.
>

+1.

--
With Regards,
Amit Kapila.