On Wed, Feb 11, 2026 at 2:14 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Tuesday, February 10, 2026 5:34 PM shveta malik <shveta.malik@gmail.com> 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