Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database - Mailing list pgsql-bugs

From Dilip Kumar
Subject Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database
Date
Msg-id CAFiTN-vq=aHQ_-rPCPJbx2ZX6JGNzDdJjOADYLO2HgoYb8+hdw@mail.gmail.com
Whole thread Raw
In response to RE: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Responses Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database
List 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 by date:

Previous
From: Alexandre Bailly
Date:
Subject: Re: BUG #19003: A SELECT that does not return a valid table
Next
From: Dilip Kumar
Date:
Subject: Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database