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

Поиск
Список
Период
Сортировка
От Petr Jelinek
Тема Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)
Дата
Msg-id 3e59fc8e-fdd0-6cc5-b2c1-cf030e19e45b@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION,query cancellations and slot handling)  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On 09/05/17 10:51, Masahiko Sawada wrote:
> On Tue, May 9, 2017 at 5:39 PM, Petr Jelinek
> <petr.jelinek@2ndquadrant.com> wrote:
>> 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.
> 
> IIUC in this design, for example if we mistakenly create a
> subscription without creating replication slot and corresponding
> replication slot doesn't exist on publisher, we cannot drop
> subscription until we create corresponding replication slot manually.
> Isn't it become a problem for user?
> 

We can, that's why the NONE value for slot name was added by the patch
so that subscription can be made "slot-less". The change of
RESTRICT/CASCADE behavior that Peter made is just about whether we
refuse to drop subscription by default when there is slot associated
with or if we just go straight to dropping the slot.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade
Следующее
От: Erik Rijkers
Дата:
Сообщение: Re: [HACKERS] snapbuild woes