Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database
От | Dilip Kumar |
---|---|
Тема | Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database |
Дата | |
Msg-id | CAFiTN-vq=aHQ_-rPCPJbx2ZX6JGNzDdJjOADYLO2HgoYb8+hdw@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database
|
Список | pgsql-bugs |
On Thu, Jul 31, 2025 at 2:34 PM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > > Dear Vignesh, Dilip, > > I found another corner case: > > ``` > postgres=# CREATE SUBSCRIPTION sub CONNECTION 'dbname=db1 user=postgres port=5431' PUBLICATION pub1 WITH (connect=false,slot_name=sub); > WARNING: subscription was created, but is not connected > HINT: To initiate replication, you must manually create the replication slot, enable the subscription, and refresh thesubscription. > CREATE SUBSCRIPTION > postgres=# DROP SUBSCRIPTION sub ; > ... (won't return) > ``` > > Because still can explicitly specify the slot_name while creating the subscription. > Another pattern is to run ALTER SUBSCRIPTION SET (slot_name) command after the > CREATE SUBSCRIPTION WITH (connect=false);. > > Should we fix the case? If so, how? IMHO, what we should do is to set a flag in subscription that whether the connect is true or not, and drop subscription should not try to drop the slot if the connect is false, thoughts? -- Regards, Dilip Kumar Google
В списке pgsql-bugs по дате отправления: