On Thu, Nov 6, 2025 at 12:03 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Thursday, October 30, 2025 7:01 AM Masahiko Sawada <sawada.mshk@gmail.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.
