On 02/05/17 15:14, Petr Jelinek wrote: > On 02/05/17 15:10, Tom Lane wrote: >> Robert Haas <robertmh...@gmail.com> writes: >>>> On Thu, Apr 20, 2017 at 7:46 AM, Petr Jelinek >>>> <petr.jeli...@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
