On Sat, Jan 22, 2022 at 4:33 AM Hsu, John <hsuchen@amazon.com> wrote:
>
> > I might be missing something but isn’t it okay even if the new primary
> > server is behind the subscribers? IOW, even if two slot's LSNs (i.e.,
> > restart_lsn and confirm_flush_lsn) are behind the subscriber's remote
> > LSN (i.e., pg_replication_origin.remote_lsn), the primary sends only
> > transactions that were committed after the remote_lsn. So the
> > subscriber can resume logical replication with the new primary without
> > any data loss.
>
> Maybe I'm misreading, but I thought the purpose of this to make
> sure that the logical subscriber does not have data that has not been
> replicated to the new primary. The use-case I can think of would be
> if synchronous_commit were enabled and fail-over occurs. If
> we didn't have this set, isn't it possible that this logical subscriber
> has extra commits that aren't present on the newly promoted primary?
>
This is very much possible if the new primary used to be asynchronous
standby. But, it seems like the current patch is trying to hold the
logical replication until the data has been replicated to the physical
standby when synchronous_slot_names is set. This will ensure that the
logical subscriber is never ahead of the new primary. However, AFAIU
that's not the primary use-case of this patch; instead this is to
ensure that the logical subscribers continue getting data from the new
primary when the failover occurs.
>
> If a logical slot was dropped on the writer, should the worker drop logical
> slots that it was previously synchronizing but are no longer present? Or
> should we leave that to the user to manage? I'm trying to think why users
> would want to sync logical slots to a reader but not have that be dropped
> as well if it's no longer present.
>
AFAIU this should be taken care of by the background worker used to
synchronize the replication slot.
--
With Regards,
Ashutosh Sharma.
