On 09/05/17 16:28, Peter Eisentraut wrote:
> 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.
>
> Committed.
>
> I also wrote a bit of documentation about slot handling for
> subscriptions, covering some of what was discussed in this thread.
>
Great, thanks.
Here is rebased version of the other patch (the interface rework). I
also fixed the tab completion there.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
