Subject: Re: logical replication syntax (was DROP SUBSCRIPTION,
 query cancellations and slot handling)
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>
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>
Cc: Robert Haas <robertmhaas@gmail.com>,
 Michael Paquier <michael.paquier@gmail.com>,
 PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <b54076fd-67d4-cc80-d5a6-ee8db2528e17@2ndquadrant.com>
Date: Tue, 9 May 2017 10:28:02 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
 Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <5f6ad263-af87-2aee-b86b-8bf7e3260b73@2ndquadrant.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, 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