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.
> > 2)
> > When 'synchronized_standby_slots' is configured but standby named in
> > it is down blocking logical replication, then we get a WARNING in
> > subscriber's log file:
> >
> > WARNING: replication slot "standby_2" specified in parameter
> > synchronized_standby_slots does not have active_pid.
> > DETAIL: Logical replication is waiting on the standby associated with
> > "standby_2".
> > HINT: Consider starting standby associated with "standby_2" or amend
> > parameter synchronized_standby_slots.
> >
> > But OTOH, when 'synchronous_standby_names' is configured instead of
> > 'synchronized_standby_slots' and any of the standbys listed is down
> > blocking logical replication, we do not get any sort of warning. It is
> > inconsistent behavior. Also user might be left clueless on why
> > subscribers are not getting changes.
Ah that's a gap. Let me add some logging/warning in a similar fashion.
Although I think I'd have the warning be relatively generic (e.g.
changes are blocked because
they're not synchronously committed)
Thanks,
--
John Hsu - Amazon Web Services