From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: 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, 2 May 2017 15:22:34 +0200
Message-ID: <9174dc31-787a-a2f6-818f-cb4a5c1dfddb@2ndquadrant.com> (raw)
In-Reply-To: <360a1932-7af4-609b-94f1-2ad419430869@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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 02/05/17 15:14, Petr Jelinek wrote:
> On 02/05/17 15:10, Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>>> On Thu, Apr 20, 2017 at 7:46 AM, Petr Jelinek
>>>> <petr.jelinek@2ndquadrant.com> wrote:
>>>>> DROP SUBSCRIPTION mysub NODROP SLOT;
>>
>>>> I'm pretty uninspired by this choice of syntax.
>>
>> Actually, this command has got much worse problems than whether you like
>> the spelling of its option: it shouldn't have an option in the first
>> place. I put it to you as an inviolable rule that no object DROP command
>> should ever have any options other than RESTRICT/CASCADE and IF EXISTS.
>> If it does, then you don't know what to do when the object is recursed
>> to by a cascaded drop.
>>
>> It's possible that we could allow exceptions to this rule for object types
>> that can never have any dependencies. But a subscription doesn't qualify
>> --- it's got an owner, so DROP OWNED BY already poses this problem. Looks
>> to me like it's got a dependency on a database, too. (BTW, if
>> subscriptions are per-database, why is pg_subscription a shared catalog?
>> There were some pretty schizophrenic decisions here.)
>
> Because otherwise we would need launcher process per database, not pretty.
>
>>
>> So ISTM we need to get rid of the above-depicted syntax. We could instead
>> have what-to-do-with-the-slot as a property of the subscription,
>> established at CREATE SUBSCRIPTION and possibly changed later by ALTER
>> SUBSCRIPTION. Not quite sure what to call the option, maybe something
>> based on the concept of the subscription "owning" the slot.
>>
>
> So what do you do if the upstream does not exist anymore when you are
> dropping subscription?
>
Let me expand, if we don't drop the slot by default when dropping
subscription, we'll have a lot of users with dead slots laying around
holding back WAL/catalog_xmin, that's really bad. If we do drop by
default like now, we need option to not do that, neither RESTRICT, nor
CASCADE fit that.
--
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, 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: <9174dc31-787a-a2f6-818f-cb4a5c1dfddb@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