Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d5aVB-00026J-3R for pgsql-hackers@arkaria.postgresql.org; Tue, 02 May 2017 16:18:13 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d5aVA-0006tc-Hx for pgsql-hackers@arkaria.postgresql.org; Tue, 02 May 2017 16:18:12 +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 1d5aTc-0003sw-65 for pgsql-hackers@postgresql.org; Tue, 02 May 2017 16:16:36 +0000 Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1d5aTY-0000nA-Dk for pgsql-hackers@postgresql.org; Tue, 02 May 2017 16:16:35 +0000 Received: by mail-wm0-x230.google.com with SMTP id r190so26323622wme.1 for ; Tue, 02 May 2017 09:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=m9T/M7gyRM1YE1ovg+j1/0cjTDfk4PI9RW+D3QLHuSU=; b=i6otTM/ej7CltWaJYjeykFlsxVYFXJdOAW5bUUr3DSzHJ/mjAueHcwgGJKbtjpHBJi GKBhiSg3rEyPBig0kl69ExxlgFjF1lYw2PH4ZnL5VLtJAGW7z6ZxRKmnxkveAKB6bR8U G7T5lSGtjArzEb1ilb5dAQL4mE4D7+NoiUwoqaQhqqvzlcZTRftZdbTYPCqnP/BdO5lz /lSL+R2UlYX8y4KMgFErBynES+O7EYgDy7gHZR9WhjK5z/2dt7oFWYTPK6vXgrLQhCzO Y+IpJdlEXvOTNdAMyOE4A3bBkcBUBFkkFnSfRy4p6AwOlk9931O72LtgOX790taBXMrE AsSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=m9T/M7gyRM1YE1ovg+j1/0cjTDfk4PI9RW+D3QLHuSU=; b=E8Ih23ol0zQBsMTcU/NVjulug2f7Sjj2BFP81GLQqS34AukU8fiHE3PleOPpgGFuvF MfcP55SuMWqSa+DfB0HlkU5TENuXpFIaAfF2UF0HwXAjP4ulKmIPfdpbLU9sh3mfnxN0 ZWqQp1mef+TYVBZvLe89muDgczgX5ovi3WH3igP7tYmy0b5+JWVKJcuGgK7eH+Fp85SY KR1MD9LchqGIRMca61skqqKZ6t+yATXXSufXoiaCW4FXcODrq2odkZJhhyrec4sMAVWB cZxFqPV6tqKS6BY7Sf/0wiOKOSznjR+INdBcjs4MOudJg6GIKQmXAW9YHcDWn+0kK1vj pTcQ== X-Gm-Message-State: AN3rC/7vWa0t8a69KADARcHnjBWoNkoz2qe/cshoILYzVimw2Iculp4R Msq8t88N/AOO5O/lo4+cHjq2DQdt13dzcvd/zgSx9IL0QiBlaX0ZYoKKH6fbJl+vyYydRCGEIYi X+b+Q5HHr779LZUUdAMVAoUHf4ogs4axOoMP/kxTevI8Adz7d+5Ns8zsR/POLs8GPTJjcG4MW X-Received: by 10.28.135.130 with SMTP id j124mr3108198wmd.125.1493741790596; Tue, 02 May 2017 09:16:30 -0700 (PDT) Received: from [192.168.0.105] (150.123.broadband11.iol.cz. [90.178.123.150]) by smtp.gmail.com with ESMTPSA id u76sm24290576wrb.27.2017.05.02.09.16.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 09:16:29 -0700 (PDT) Subject: Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling) To: Robert Haas , Alvaro Herrera References: <20170502154959.r45gitdimklbcrwt@alvherre.pgsql> Cc: Tom Lane , Michael Paquier , PostgreSQL mailing lists From: Petr Jelinek Message-ID: Date: Tue, 2 May 2017 18:16:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) 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 On 02/05/17 18:00, Robert Haas wrote: > On Tue, May 2, 2017 at 11:49 AM, Alvaro Herrera > wrote: >> Petr Jelinek wrote: >>> So the only way to fulfill the requirement you stated is to just not try >>> to drop the slot, ever, on DROP SUBSCRIPTION. That makes the default >>> behavior leave resources on upstream that will eventually cause that >>> server to stop unless user notices before. I think we better invent >>> something that limits how much inactive slots can hold back WAL and >>> catalog_xmin in this release as well then. >> >> I don't understand why isn't the default behavior to unconditionally >> drop the slot. Why do we ever want the slot to be kept? > > What if the remote server doesn't exist any more? > Or what if the slot is used by other subscription (because you restored dump containing subscriptions to another server for example), or you have server that does not have outside network access anymore, or many other reasons. -- 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