RE: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database
От | Hayato Kuroda (Fujitsu) |
---|---|
Тема | RE: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database |
Дата | |
Msg-id | OSCPR01MB14966AAD2EEA95C752DB8904CF527A@OSCPR01MB14966.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database
Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database |
Список | pgsql-bugs |
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 the subscription. 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? Best regards, Hayato Kuroda FUJITSU LIMITED
В списке pgsql-bugs по дате отправления: