On Wed, Jan 3, 2024 at 12:09 PM vignesh C <vignes...@gmail.com> wrote: > > 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) >
Can't we simply do it by starting the server with max_logical_replication_workers = 0 or is there some other need to start in binary upgrade mode? b) Disable > the subscriptions > Why not simply drop the subscriptions? c) Drop the replication slots d) Drop the > publications > I am not so sure about dropping publications because, unlike subscriptions which can start to pull the data, there is no harm with publications. Similar to publications there could be some user-defined functions or other other objects which may not be required once the standby replica is converted to subscriber. I guess we need to leave those to the user. 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 agree that some kind of switch to control this action would be useful. -- With Regards, Amit Kapila.
