On 5/9/17 04:39, Petr Jelinek wrote:
>>> 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.


I also wrote a bit of documentation about slot handling for
subscriptions, covering some of what was discussed in this thread.

Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to