Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On Tue, May 9, 2017 at 5:57 PM, Petr Jelinek
<petr.jelinek@2ndquadrant.com> wrote:
> 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".

Yeah, but since we can still create subscription with only NOCREATE
SLOT option (option name will be changed but still exists), if we do
that then non-NULL value is stored into subslotname and the
subscription is enable. We can drop such subscription after disabled
it and after set its slot name to NONE. But I think it's still not
good for user..

> 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.
>

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center