On Thu, Nov 6, 2025 at 2:36 AM Amit Kapila <[email protected]> wrote: > > 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.
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
