Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cGbBH-00011f-Hu for pgsql-committers@arkaria.postgresql.org; Tue, 13 Dec 2016 00:42:55 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cGbBH-0000Mh-55 for pgsql-committers@arkaria.postgresql.org; Tue, 13 Dec 2016 00:42:55 +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 1cGbBG-0000MT-NR for pgsql-committers@postgresql.org; Tue, 13 Dec 2016 00:42:54 +0000 Received: from mail-wm0-x233.google.com ([2a00:1450:400c:c09::233]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cGbBD-0004VK-HY for pgsql-committers@postgresql.org; Tue, 13 Dec 2016 00:42:54 +0000 Received: by mail-wm0-x233.google.com with SMTP id f82so95380280wmf.1 for ; Mon, 12 Dec 2016 16:42:51 -0800 (PST) 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=PwYZ6tjcPILxU8WspwdTCxLxdY62XCgB5Co8jXuTAMo=; b=JHNO+qPnLo6lwtCV2f4vfNzbaiwHXYobqrxdYua8Sg8Nmq8U3wJ3Ms8MGc+LbGb3UJ iVJntbDT8ZilGfELq3qnLqoNNypLJZi7Vyc2J/+4Jz8yN1uYQc2W6GcLdeX6mF+KMzv6 MA8GvQyjURt9N5hzhBLSR1ImNsrpBo7eJxtkTb+Ntyu0v9hdNO1JXPNDX0WLMT7D0meb P88M1wVrj4Vd6cYohvossD2S1Jf1X5PwiCRKj/DtpDfWNyC0YPHlDhowb7khs18xDPU/ ztBhOBphVQHyYZFJKuPkSb1SWeYq0sQ7JUnr8Uv6P2DyRX2icfowBUhYflYoehrwDCeY Ql/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PwYZ6tjcPILxU8WspwdTCxLxdY62XCgB5Co8jXuTAMo=; b=fiwgx3wDKpA+J4hIjb8tzomNdfokhuIE5y78DcGpdLp89SsJ8P3xiDqxC8cpnn087T C465rK7eb33WjiBiZWjxBzuUBL6Ltm06+K3Xs5SZD7pRVNOpcbFrr8M1Qe6qTl8RGcM4 Viz5vlmR+Cvo/Ns2t/S7HIYT6ThPfz9rCSwcSeewOcFDdOYU+wbiNFqEIkqsC9Utn8v+ /hpmE/pYezRZA7FFBGA2cMOqMe9vslXBeyztFeW3xCEsqL60Qn45PT94dwd/2nJESyEm 371zFS3/frSGIX+SmjqsJKHAOOjnPWA/YVMT+KFZAwgYDEBWzm+BEgES+HCz/D0VxB/1 eOzA== X-Gm-Message-State: AKaTC02A98hIEUmx2lBYgwgxTTnO1mZLFdPL8bMvzJugd2iGmJThnU9gxIY6HwrJxpNR0lCC X-Received: by 10.28.174.194 with SMTP id x185mr151679wme.4.1481589770309; Mon, 12 Dec 2016 16:42:50 -0800 (PST) Received: from [192.168.0.105] (150.123.broadband11.iol.cz. [90.178.123.150]) by smtp.gmail.com with ESMTPSA id d17sm59640503wjr.14.2016.12.12.16.42.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Dec 2016 16:42:49 -0800 (PST) Subject: Re: pgsql: Add support for temporary replication slots To: Tom Lane References: <27274.1481557380@sss.pgh.pa.us> <27833.1481558144@sss.pgh.pa.us> <62935e6f-4f1b-c433-e0fa-7f936a38b3e5@2ndquadrant.com> <22907.1481571177@sss.pgh.pa.us> <15713.1481585953@sss.pgh.pa.us> <314cae39-2e7d-f5a3-d226-cfb80cf80481@2ndquadrant.com> <18684.1481589637@sss.pgh.pa.us> Cc: Peter Eisentraut , pgsql-committers@postgresql.org, Andres Freund From: Petr Jelinek Message-ID: <48b2c017-695d-b5ac-2ff4-89b939b3e8f9@2ndquadrant.com> Date: Tue, 13 Dec 2016 01:42:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <18684.1481589637@sss.pgh.pa.us> Content-Type: text/plain; charset=windows-1252 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-committers Precedence: bulk Sender: pgsql-committers-owner@postgresql.org On 13/12/16 01:40, Tom Lane wrote: > Petr Jelinek writes: >> On 13/12/16 00:39, Tom Lane wrote: >>> Hm, buildfarm says this didn't fix it. Where exactly does the dropping >>> of the slot happen ... is it not complete by the time the backend exits? > >> Yes, I've seen. The cleanup of slots is done in ProcKill(), I wonder, >> since it's on_shmem_exit hook, and the pgstat_beshutdown_hook is as >> well, maybe the pgstat_beshutdown_hook is called before ProcKill and the >> query is lucky to hit right in between. > > Hm. That seems like a pretty bogus place to do it. An awful lot of the > backend infrastructure is already gone by then, if I recall the ordering > correctly. Maybe ShutdownPostgres would be a saner place; but it really > depends on what you think the module layering is for this facility. > I would definitely not think it is proc.c's responsibility, though. > Well, the problem is that that's the place where the currently active slot is released (if there was an active one). So we'd need to move that part somewhere else as well. I am not sure what's the reasoning for releasing it at that specific spot so CCing Andres. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers