Re: Allow logical replication in the same cluster

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Allow logical replication in the same cluster
Дата
Msg-id CAA4eK1JguoT0JDw8MAhOX9dRe4qXGR0g_gBUiiR9qfpW4vaj_g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Allow logical replication in the same cluster  (Chao Li <li.evan.chao@gmail.com>)
Список pgsql-hackers
On Mon, Sep 8, 2025 at 8:20 AM Chao Li <li.evan.chao@gmail.com> wrote:
>
> Hi Amit,
>
> Thanks for your info.
>
> On Sep 6, 2025, at 12:32, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> You can avoid this problem by creating a slot first on publisher with
> something like:
> postgres=# select pg_create_logical_replication_slot('s1', 'pgoutput',
> false, true);
> pg_create_logical_replication_slot
> ------------------------------------
> (s1,0/01BFF178)
> (1 row)
>
> Then while creating subscription you can use the above created slot as follows:
> db1=# create subscription sub1 connection 'dbname=postgres'
> publication pub1 WITH(create_slot=false, slot_name='s1');
> CREATE SUBSCRIPTION
>
> --
> With Regards,
> Amit Kapila.
>
>
> I am aware of this workaround solution. When I encountered the “create subscription” stuck problem, I did a Google
search,then I found the old discussion thread that mentioned a workaround, so I did further search and eventually
figuredout the workaround. 
>
> I think it’s worth resolving this issue, because it avoids confusion from people who want to try or test logical
replicationlogically, and allows the same script to run in both an pure local environment and a real non-local
environment.WDYT? 
>

I don't see why someone can't use the workaround provided. The
solution proposed is more like adding hacks in the code making it a
maintenance burden.

--
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления: