On Mon, Jul 22, 2024 at 9:12 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Fri, Jul 19, 2024 at 2:52 AM John H <johnhyvr@gmail.com> wrote:
> >
> > Hi Shveta,
> >
> > Thanks for taking a look at the patch.
> >
> > > > will leave user no option to unlink failover-enabled logical
> > > > subscribers from the wait on synchronous standbys.
> >
> > That's a good point. I'm a bit biased in that I don't think there's a
> > great reason why someone would
> > want to replicate logical changes out of the synchronous cluster
> > without it having been synchronously replicated
> > but yes this would be different behavior compared to strictly the slot one.
> >
> > > ...
> > > So when 'synchronized_standby_slots' is comma separated list, we pick
> > > those slots; if it is empty, then no wait on standbys, and if its
> > > value is 'DEFAULT' as configured by user, then go with
> > > 'synchronous_standby_names'. Thoughts?
> >
> > I think I'd prefer having a separate GUC if the alternative is to reserve
> > special keywords in 'synchronized_standby_slots' but I'm not sure if I
> > feel strongly about that.
>
> My only concern is, earlier we provided a way to set the failover
> property of slots even without mandatorily wait on physical standbys.
> But now we will be changing this behaviour.
>
Adding a new GUC as John suggests addressing this concern is one way
to go but we should think some more before adding a new GUC. Then
second as you are proposing to add a special value for GUC
synchronized_standby_slots will also have a downside in that it will
create dependency among two GUCs (synchronized_standby_slots and
synchronous_standby_names) which can also make the code complex.
Yet another possibility is to have a slot-level parameter (something
like failover_wait_for) which can be used to decide the GUC preference
for failover-enabled slots.
As this is a new feature and we haven't got much feedback from users
so like John, I am also not very sure how much merit we have in
retaining the old behavior where failover slots don't need to wait for
any of the standbys. But anyway, we have at least some escape route
where logical subscribers keep on waiting for some physical standby
that is down to come back and one may want to use that in some
situations, so there is clearly some value in retaining old behavior.
--
With Regards,
Amit Kapila.