From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)
Date: Tue, 9 May 2017 10:39:09 +0200
Message-ID: <5f6ad263-af87-2aee-b86b-8bf7e3260b73@2ndquadrant.com> (raw)
In-Reply-To: <35f3592b-8582-e348-1823-f8edfcf03ba3@2ndquadrant.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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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.
>
> Here is your patch amended for that.
>
I am fine with this mechanism as well.
--
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: petr.jelinek@2ndquadrant.com, peter.eisentraut@2ndquadrant.com, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, michael.paquier@gmail.com
Subject: Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)
In-Reply-To: <5f6ad263-af87-2aee-b86b-8bf7e3260b73@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox