Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling) - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)
Date
Msg-id 3e59fc8e-fdd0-6cc5-b2c1-cf030e19e45b@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On 09/05/17 10:51, Masahiko Sawada wrote:
> On Tue, May 9, 2017 at 5:39 PM, Petr Jelinek
> <petr.jelinek@2ndquadrant.com> wrote:
>> On 09/05/17 07:07, Peter Eisentraut wrote:
>>> On 5/8/17 23:23, Peter Eisentraut wrote:
>>>> The way this uses RESTRICT and CASCADE appears to be backwards from its
>>>> usual meaning.  Normally, CASCADE when dropping an object that is still
>>>> used by others will cause those other objects to be dropped.  The
>>>> equivalent here would be DROP REPLICATION SLOT + CASCADE would drop the
>>>> subscription.
>>>>
>>>> What we want to simulate instead is an "auto" dependency of the slot on
>>>> the subscription.  So you can drop the slot separately (subject to other
>>>> restrictions), and it is dropped automatically when the subscription is
>>>> dropped.  To avoid that, you can disassociate the slot from the
>>>> subscription, which you have implemented.
>>>>
>>>> I think we can therefore do without RESTRICT/CASCADE here.  If a slot is
>>>> associated with the subscription, it should be there when we drop the
>>>> subscription.  Otherwise, the user has to disassociate the slot and take
>>>> care of it manually.  So just keep the "cascade" behavior.
>>>>
>>>> Similarly, I wouldn't check first whether the slot exists.  If the
>>>> subscription is associated with the slot, it should be there.
> 
> IIUC in this design, for example if we mistakenly create a
> subscription without creating replication slot and corresponding
> replication slot doesn't exist on publisher, we cannot drop
> subscription until we create corresponding replication slot manually.
> Isn't it become a problem for user?
> 

We can, that's why the NONE value for slot name was added by the patch
so that subscription can be made "slot-less". The change of
RESTRICT/CASCADE behavior that Peter made is just about whether we
refuse to drop subscription by default when there is slot associated
with or if we just go straight to dropping the slot.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade
Next
From: Erik Rijkers
Date:
Subject: Re: [HACKERS] snapbuild woes