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>
 <3e59fc8e-fdd0-6cc5-b2c1-cf030e19e45b@2ndquadrant.com>
 <CAD21AoBpYDsH9o0zXUJW-09o2zWNPs+sqUgkrNK3CNzyBjjJtQ@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: <ad83b4a4-613e-bb58-f153-613efe6d5429@2ndquadrant.com>
Date: Tue, 9 May 2017 11:54:52 +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: 
 <CAD21AoBpYDsH9o0zXUJW-09o2zWNPs+sqUgkrNK3CNzyBjjJtQ@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 11:44, Masahiko Sawada wrote:
> On Tue, May 9, 2017 at 5:57 PM, Petr Jelinek
> <petr.jelinek@2ndquadrant.com> wrote:
>> 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".
> 
> Yeah, but since we can still create subscription with only NOCREATE
> SLOT option (option name will be changed but still exists), if we do
> that then non-NULL value is stored into subslotname and the
> subscription is enable. We can drop such subscription after disabled
> it and after set its slot name to NONE. But I think it's still not
> good for user..
> 

Well that's why I originally had the options directly as part of DROP
SUBSCRIPTION. But if you read the discussion in this thread, that's not
something we should be doing. There is no sensible way of mapping the
nodrop behavior to the only allowed options of RESTRICT and CASCADE so
there is not much we can do other than the ALTER.

-- 
  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