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.
Here is your patch amended for that. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
v2-0001-Remove-the-NODROP-SLOT-option-from-DROP-SUBSCRIPT.patch
Description: invalid/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
