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?
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
