On 5/8/17 17:55, Petr Jelinek wrote:
> On 08/05/17 22:55, Peter Eisentraut wrote:
>> On 5/5/17 13:01, Petr Jelinek wrote:
>>> What do you think of attached. I actually did add RESTRICT/CASCADE, in a
>>> way that if there is slot RESTRICT will refuse to drop subscription and
>>> CASCADE will try to drop it. Still all errors.
>>>
>>> The new way to not drop slot is to set slot_name to NONE which is new
>>> value that I invented (inspiration from OWNED BY sequences) which
>>> basically disassociates the subscription from slot.
>>>
>>> It's slightly less automatic this way but perhaps that's not a bad
>>> thing, at least nobody will drop slots by mistake while we still make
>>> sure that slots are not left over without anybody noticing.
>>
>> I think this is OK. Could you send a version of this patch based on
>> master please?
>>
>
> Here it is.
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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services