Subject: Re: speed up a logical replica setup

From: Ashutosh Bapat <[email-masked]>
Date: Thu, 4 Jan 2024 12:30:05 +0530

On Wed, Jan 3, 2024 at 2:49 PM Amit Kapila <[email-masked]> 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?

-- 
Best Wishes,
Ashutosh Bapat

---

From: Amit Kapila <[email-masked]>
Date: Thu, 4 Jan 2024 16:34:13 +0530

> is supported. But what good is having the same publications as primary

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.