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

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)
Date: 2017-05-09 07:27:19
Message-ID: CAD21AoDwJHTPn9ZN34AVLZrCD4BqSfKUJnnuGMaks2O_0RZrbQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 9, 2017 at 2:07 PM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> 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 think we should change tab-completion support for that as well.

diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index 183fc37..046fdd5 100644
--- a/src/bin/psql/tab-complete.c
+++ b/src/bin/psql/tab-complete.c
@@ -2684,7 +2684,7 @@ psql_completion(const char *text, int start, int end)

/* DROP SUBSCRIPTION */
else if (Matches3("DROP", "SUBSCRIPTION", MatchAny))
- COMPLETE_WITH_LIST2("DROP SLOT", "NODROP SLOT");
+ COMPLETE_WITH_LIST2("CASCADE", "RESTRICT");

/* EXECUTE */
else if (Matches1("EXECUTE"))

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeevan Ladhe 2017-05-09 08:21:30 Re: Bug in pg_dump --table and --exclude-table for declarative partition table handling.
Previous Message Rahila Syed 2017-05-09 07:19:10 Re: Adding support for Default partition in partitioning