On Thu, Jan 4, 2024 at 12:30 PM Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote: > > On Wed, Jan 3, 2024 at 2:49 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > 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. > > > > IIUC, primary use of pg_subscriber utility is to start a logical > subscription from a physical base backup (to reduce initial sync time) > as against logical backup taken while creating a subscription. Hence I > am expecting that apart from this difference, the resultant logical > replica should look similar to the logical replica setup using a > logical subscription sync. Hence we should not leave any replication > objects around. UDFs (views, and other objects) may have some use on a > logical replica. We may replicate changes to UDF once DDL replication > is supported. But what good is having the same publications as primary > also on logical replica? >
The one use case that comes to my mind is to set up bi-directional replication. The publishers want to subscribe to the new subscriber. -- With Regards, Amit Kapila.