On 02/05/17 18:25, Alvaro Herrera wrote:
> Petr Jelinek wrote:
>> On 02/05/17 18:00, Robert Haas wrote:
>>> On Tue, May 2, 2017 at 11:49 AM, Alvaro Herrera
>>> <alvherre@2ndquadrant.com> wrote:
>>>> Petr Jelinek wrote:
>>>>> So the only way to fulfill the requirement you stated is to just not try
>>>>> to drop the slot, ever, on DROP SUBSCRIPTION. That makes the default
>>>>> behavior leave resources on upstream that will eventually cause that
>>>>> server to stop unless user notices before. I think we better invent
>>>>> something that limits how much inactive slots can hold back WAL and
>>>>> catalog_xmin in this release as well then.
>>>>
>>>> I don't understand why isn't the default behavior to unconditionally
>>>> drop the slot. Why do we ever want the slot to be kept?
>>>
>>> What if the remote server doesn't exist any more?
>>
>> Or what if the slot is used by other subscription (because you restored
>> dump containing subscriptions to another server for example), or you
>> have server that does not have outside network access anymore, or many
>> other reasons.
>
> So there are two different scenarios: one is that you expect the slot
> drop to fail for whatever reason; the other is that you want the slot to
> be kept because it's needed for something else. Maybe those two should
> be considered separately.
>
> 1) keep the slot because it's needed for something else.
> I see two options:
> a) change the something else so that it uses another slot with the
> same location. Do we have some sort of "clone slot" operation?
Nope.
> b) have an option to dissociate the slot from the subscription prior
> to the drop.
>
We do have ALTER SUBSCRIPTION bla WITH (SLOT NAME = 'something') so this
is definitely doable but ALTER SUBSCRIPTION bla WITH (SLOT NAME = '') is
not very nice syntax, maybe something like RESET SLOT NAME?
> 2) don't drop because we know it won't work. I see two options:
> c) ignore a drop slot failure, i.e. don't cause a transaction abort.
> An easy way to implement this is just add a PG_TRY block, but we
> dislike adding those and not re-throwing the error.
> d) rethink drop slot completely; maybe instead of doing it
> immediately, it should be a separate task, so we first close the
> current transaction (which dropped the subscription) and then we open
> a second one to drop the slot, so that if the drop slot fails, the
> subscription does not come back to life.
>
Yeah I was thinking about ignoring failures with WARNING as well, but
never seemed right because it would not solve the case 1), but I didn't
think of b) which might solve it.
I was also thinking on how to map the behavior to RESTRICT vs CASCADE,
wonder if RESTRICT should check for slot existence and refuse to drop if
the slot exists (question is then should it bail on connection failure
or ignore it?) and CASCADE should try to drop the slot and only warn on
failure then.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services