On Tue, May 9, 2017 at 5:57 PM, Petr Jelinek <petr.jeli...@2ndquadrant.com> wrote: > On 09/05/17 10:51, Masahiko Sawada wrote: >> On Tue, May 9, 2017 at 5:39 PM, Petr Jelinek >> <petr.jeli...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
