Re: speed up a logical replica setup
От | Ashutosh Bapat |
---|---|
Тема | Re: speed up a logical replica setup |
Дата | |
Msg-id | CAExHW5t4ew7ZrgcDdTv7YmuG7LVQT1ZaEny_EvtngHtEBNyjcQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: speed up a logical replica setup (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: speed up a logical replica setup
|
Список | pgsql-hackers |
On Wed, Jan 3, 2024 at 2:49 PM Amit Kapila <amit.kapila16@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? -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: