On Wed, 3 Jan 2024 at 14:49, Amit Kapila <amit.kapil...@gmail.com> wrote: > > 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?
I agree, max_logical_replication_workers = 0 is enough for our case. > b) Disable > > the subscriptions > > > > Why not simply drop the subscriptions? Dropping subscriptions is ok as these subscriptions will not be required. > 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. Yes, that makes sense. Regards, Vignesh