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