Subject: Re: logical replication syntax (was DROP SUBSCRIPTION,
 query cancellations and slot handling)
To: Masahiko Sawada <sawada.mshk@gmail.com>
References: 
 <CA+TgmoZmkbpAWRzVKDVcHnTBkYjJEFS8=09RL-G3zgdozCLFHQ@mail.gmail.com>
 <27478.1493727233@sss.pgh.pa.us> <29431.1493730652@sss.pgh.pa.us>
 <360a1932-7af4-609b-94f1-2ad419430869@2ndquadrant.com>
 <9174dc31-787a-a2f6-818f-cb4a5c1dfddb@2ndquadrant.com>
 <30166.1493731904@sss.pgh.pa.us>
 <daf9909a-7033-9cfe-a8cc-a606025820fc@2ndquadrant.com>
 <2b931e0e-d9f2-c79e-b74b-91df2f915e66@2ndquadrant.com>
 <96e95255-94d9-0881-16ba-bdb6d05bb307@2ndquadrant.com>
 <52a1f160-db1f-49c6-9832-498dbea58ae8@2ndquadrant.com>
 <35f3592b-8582-e348-1823-f8edfcf03ba3@2ndquadrant.com>
 <5f6ad263-af87-2aee-b86b-8bf7e3260b73@2ndquadrant.com>
 <CAD21AoDJ+3S_2KkPLqx2tQAOPj_RwV8E3X8U-wyHMuyBQ58YUw@mail.gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
 Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
 Michael Paquier <michael.paquier@gmail.com>,
 PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Message-ID: <3e59fc8e-fdd0-6cc5-b2c1-cf030e19e45b@2ndquadrant.com>
Date: Tue, 9 May 2017 10:57:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
 <CAD21AoDJ+3S_2KkPLqx2tQAOPj_RwV8E3X8U-wyHMuyBQ58YUw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


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