Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHYLI-0006fH-UZ for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Oct 2018 18:02:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gHYLH-00077y-7K for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Oct 2018 18:02:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHYLG-00077q-Sf for pgsql-hackers@lists.postgresql.org; Tue, 30 Oct 2018 18:02:15 +0000 Received: from lists.commandprompt.com ([2604:da00:2:2:5054:ff:fe07:7618]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHYL9-0006Mp-4l for pgsql-hackers@postgresql.org; Tue, 30 Oct 2018 18:02:13 +0000 Received: from [192.168.50.9] (spinlock.commandprompt.com [69.168.55.30]) by lists.commandprompt.com (Postfix) with ESMTPA id F353A7C7; Tue, 30 Oct 2018 11:02:04 -0700 (PDT) Received: from c-73-97-49-9.hsd1.wa.comcast.net ([73.97.49.9] helo=[192.168.50.9]) by assp.commandprompt.com with SMTPSA(TLSv1_2 ECDHE-RSA-AES128-GCM-SHA256) (2.5.1); 30 Oct 2018 11:02:04 -0700 Subject: Re: replication_slots usability issue To: Andres Freund , Michael Paquier Cc: Alvaro Herrera , pgsql-hackers References: <56672097-711c-126a-a63e-04e7940110ad@commandprompt.com> <20181029190218.uejy5cvgzygwrguy@alvherre.pgsql> <20181029191304.lbsmhshkyymhw22w@alap3.anarazel.de> <20181030025109.GD1644@paquier.xyz> <20181030175254.wqircsg36vblpmw5@alap3.anarazel.de> From: "Joshua D. Drake" Organization: Command Prompt, Inc. Message-ID: <47ff1ce0-498b-e305-9c72-b0cdcf41e1ce@commandprompt.com> Date: Tue, 30 Oct 2018 11:02:04 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181030175254.wqircsg36vblpmw5@alap3.anarazel.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Assp-Version: 2.5.1(16177) on assp.commandprompt.com X-Assp-ID: assp.commandprompt.com m1-22524-07470 X-Assp-Session: D0B2D20 (mail 1) X-Assp-Original-Subject: Re: replication_slots usability issue X-Assp-Client-SSL: yes List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 10/30/18 10:52 AM, Andres Freund wrote: > On 2018-10-30 11:51:09 +0900, Michael Paquier wrote: >> On Mon, Oct 29, 2018 at 12:13:04PM -0700, Andres Freund wrote: >>> I don't think this quite is the problem. ISTM the issue is rather that >>> StartupReplicationSlots() *needs* to check whether wal_level > minimal, >>> and doesn't. So you can create a slot, shutdown, change wal_level, >>> startup. A slot exists but won't work correctly. >> It seems to me that what we are looking for is just to complain at >> startup if we find any slot data and if trying to start up with >> wal_level = minimal. > Right, we really should just call CheckSlotRequirements() before doing > so. I'll make it so, once I'm actually awake and had some coffee. Why not just disable the slot and report an INFO: line? JD > > >> Er... At the same time, shouldn't RestoreSlotFromDisk() *not* use PANIC >> if more slots are found in pg_replslot than max_replication_slots can >> handle. A FATAL is fine at startup, PANIC blows up a core file, which >> is clearly overdoing it if the goal is to give a recommendation at the >> end. > I can't get particularly excited about this. I guess we can change it, > but I'd only do so in master. > > > Greetings, > > Andres Freund > -- Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc *** A fault and talent of mine is to tell it exactly how it is. *** PostgreSQL centered full stack support, consulting and development. Advocate: @amplifypostgres || Learn: https://postgresconf.org ***** Unless otherwise stated, opinions are my own. *****