On Wed, Feb 11, 2026 at 2:14 PM Zhijie Hou (Fujitsu) <[email protected]> wrote: > > On Tuesday, February 10, 2026 5:34 PM shveta malik <[email protected]> > wrote: > > > > Thanks for the patch. > > > > + * Note that we do not wait and retry if the local slot has been > > invalidated. > > + * In such cases, the corresponding remote slot on the primary is > > + likely > > + * invalidated as well. Even if only the local slot is invalidated, > > + simply > > + * retrying synchronization won't suffice, as it requires further user > > + actions > > + * to verify the server configuration, drop the invalidated slot. > > > > On thinking more, I realized that if the local slot is invalidated alone > > while the > > remote-slot is not, we do not wait for the user to drop such an invalidated > > slot. Instead slot-sync will drop it internally. See comments atop > > drop_local_obsolete_slots(). This makes me wonder whether such a case, > > where only the local slot is invalidated, should also set slotsync_pending = > > true, since there is a good chance it will get synchronized in subsequent > > runs. > > OTOH, if we do not wait for such a slot, we could end up in a situation > > where > > the slot (remote one) is valid pre-failover but is invalid (synced one) > > post- > > failover, even after running the API immediately before switchover. > > Thoughts? > > I agree that it makes sense to retry when only the local slot is invalidated. > > Here is the updated patch. >
Thanks Hou-San. I have no more comments. thanks Shveta
