Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

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.
> 
> Here is your patch amended for that.
> 

I am fine with this mechanism as well.

-- 
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services