On Thu, Nov 6, 2025 at 12:03 PM Zhijie Hou (Fujitsu) <[email protected]> wrote: > > On Thursday, October 30, 2025 7:01 AM Masahiko Sawada <[email protected]> > 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.
