Re: Assertion failure in SnapBuildInitialSnapshot()

On Thu, Nov 6, 2025 at 2:36 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> 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.

After the last slot is invalidated or dropped, both slot_xmin and
slot_catalog_xmin values are set InvalidTransactionId. Then in this
case, these values are ignored when computing the oldest safe decoding
XID in GetOldestSafeDecodingTransactionId(), no? Or do you mean that
there is a case where slot_xmin and slot_catalog_xmin retreat to a
valid XID?

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com