Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mqFsk-0007rq-PF for pgsql-docs@arkaria.postgresql.org; Thu, 25 Nov 2021 14:37:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mqFsi-0000Fz-LA for pgsql-docs@arkaria.postgresql.org; Thu, 25 Nov 2021 14:37:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mqFsh-0000Fp-T6 for pgsql-docs@lists.postgresql.org; Thu, 25 Nov 2021 14:37:48 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mqFse-0003qB-3f for pgsql-docs@lists.postgresql.org; Thu, 25 Nov 2021 14:37:47 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 924035C0196; Thu, 25 Nov 2021 09:37:41 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 25 Nov 2021 09:37:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=e5K6PW0tXyvC+KfWaMyy3OPMpBcDtZxVnY5p5Kgh72Q=; b=F9wsfn2Z rr0WClsV7US13oOMlVMVtVg/KnAR80eZIicETi7nvRYqIWwSJs1KekVeXvHFIcV6 B4IrQYp8O+3LJvuCdL5fD1kWitUwGkHhC0dmHrwFKS65EGkM9oaRiV/4PLFYQkoA t4GG09Y/tX8DRdfOTRHN3om/od8ur28vjo36qaRgpVAGWr9xP4ZCL5hFVNmcm7wj 5Vp9SNY0gR6/zoPEpH+hElqTkyJkT8tMUDmrQalEkg/S4zmJQhXAxY9XBbxhjbhC 2WpvlPEj2Q3abWXLx2dOVzGksFpi7aIqvPAfkcqM95YyvSMAIdt8PKpf01RVZso8 AMtc5sETwmVJ2Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrhedtgdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggugfgjsehmkeerre dttdejnecuhfhrohhmpeetlhhvrghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvges rghlvhhhrdhnohdqihhprdhorhhgqeenucggtffrrghtthgvrhhnpeetvdfhteeuueekfe fhfedugeffhfehhfdvleffleetkeeggeefhffggeekjedtudenucffohhmrghinhepvghn thgvrhhprhhishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 25 Nov 2021 09:37:40 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id AD44C2A0807; Thu, 25 Nov 2021 11:37:37 -0300 (-03) Date: Thu, 25 Nov 2021 11:37:37 -0300 From: Alvaro Herrera To: Kyotaro Horiguchi Cc: b1000101@pm.me, pgsql-docs@lists.postgresql.org Subject: Re: max_slot_wal_keep_size unit is not specified Message-ID: <202111251437.bfxei7ahcj6i@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="p5syqirl7mydkqrq" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211124.095013.1928208020303363469.horikyota.ntt@gmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --p5syqirl7mydkqrq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2021-Nov-24, Kyotaro Horiguchi wrote: > At Tue, 23 Nov 2021 11:21:05 -0300, Alvaro Herrera wrote in > > I wonder why did we make it round down rather than up. Does this mean > > that if you have max_slot_wal_keep_size=8MB and wal segments of 16 MB, > > the slot gets invalidated with more than zero reserved segments? > > That rounding behavior is the way we are generally doing on similar > variables. It is based on the behavior of ConvertToXSegs(). So > max_wal_size for example is rounded-up the same way. After thinking on it some more, I think rounding down is correct. If somebody sets max_slot_wal_keep_size=40MB, then by keeping the limit at 32 MB (round down) we're honoring that request better than if we made it 48 MB (round up). But in any case, I think it doesn't matter much: users need a *rough* size limit, not a super-precise one. After all, this is only verified at checkpoint time. We're probably dealing with a few hundreds of megabytes at least, so 16 MB one way or the other don't change things much. Here's a proposed patch. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "Las mujeres son como hondas: mientras más resistencia tienen, más lejos puedes llegar con ellas" (Jonas Nightingale, Leap of Faith) --p5syqirl7mydkqrq Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="0001-Document-units-for-max_slot_wal_keep_size.patch"