Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d5Xvj-0002Gq-Hx for pgsql-hackers@arkaria.postgresql.org; Tue, 02 May 2017 13:33:27 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d5Xvi-0000Ty-M3 for pgsql-hackers@arkaria.postgresql.org; Tue, 02 May 2017 13:33:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d5XuD-00065d-UG for pgsql-hackers@postgresql.org; Tue, 02 May 2017 13:31:53 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d5Xu7-0005ry-2c for pgsql-hackers@postgresql.org; Tue, 02 May 2017 13:31:53 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v42DViaF030167; Tue, 2 May 2017 09:31:44 -0400 From: Tom Lane To: Petr Jelinek cc: Robert Haas , Michael Paquier , PostgreSQL mailing lists Subject: Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling) In-reply-to: <9174dc31-787a-a2f6-818f-cb4a5c1dfddb@2ndquadrant.com> References: <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> Comments: In-reply-to Petr Jelinek message dated "Tue, 02 May 2017 15:22:34 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30165.1493731904.1@sss.pgh.pa.us> Date: Tue, 02 May 2017 09:31:44 -0400 Message-ID: <30166.1493731904@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Petr Jelinek writes: > 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. I'm not sure which part of "you can't have an option in DROP" isn't clear to you. Whatever the default behavior is always has to work, because that is what's going to happen during DROP OWNED BY, or DROP DATABASE. If you want more than one behavior during DROP, you need to drive that off something represented as a persistent property of the object, not off an option in the DROP command. I agree that RESTRICT/CASCADE don't fit this, unless the model is that the slot is always owned by the subscription, which might be too restrictive. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers