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  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andy Fan
Дата:
Сообщение: the s_lock_stuck on perform_spin_delay
Следующее
От: jian he
Дата:
Сообщение: Re: add function argument names to regex* functions.