On Wed, 1 Nov 2023 at 19:28, Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote: > > At this stage the standby would have various replication objects like > publications, subscriptions, origins inherited from the upstream > server and possibly very much active. With failover slots, it might > inherit replication slots. Is it intended that the new subscriber also > acts as publisher for source's subscribers OR that the new subscriber > should subscribe to the upstreams of the source? Some use cases like > logical standby might require that but a multi-master multi-node setup > may not. The behaviour should be user configurable.
How about we do like this: a) Starting the server in binary upgrade mode(so that the existing subscriptions will not try to connect to the publishers) b) Disable the subscriptions c) Drop the replication slots d) Drop the publications e) Then restart the server in normal(non-upgrade) mode. f) The rest of pg_subscriber work like create_all_logical_replication_slots, create_subscription, set_replication_progress, enable_subscription, etc This will be done by default. There will be an option --clean-logical-replication-info provided to allow DBA not to clean the objects if DBA does not want to remove these objects. I felt cleaning the replication information is better as a) Node-1 will replicate all the data to Node-2 (that Node-1 is subscribing to from other nodes) after pg_subscriber setup is done. b) all the data that Node-1 is publishing need not be published again by Node-2. There is an option to override if the user does not want to remove the logical replication objects. Regards, Vignesh