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 1m5al0-0007Bq-54 for pgsql-bugs@arkaria.postgresql.org; Mon, 19 Jul 2021 21:24:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m5aky-0000yd-UK for pgsql-bugs@arkaria.postgresql.org; Mon, 19 Jul 2021 21:24:56 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m5aky-0000yV-NW for pgsql-bugs@lists.postgresql.org; Mon, 19 Jul 2021 21:24:56 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m5akw-0005dN-7r for pgsql-bugs@lists.postgresql.org; Mon, 19 Jul 2021 21:24:55 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3848D5C0197; Mon, 19 Jul 2021 17:24:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 19 Jul 2021 17:24:53 -0400 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= fm3; bh=x4tmYEQ28gA022c07xp928xJG37gNVbZFrZ/81xWeMU=; b=XJloLygY 1BF4rJfDbRa8XmIy6mVlrQwHZ5EvPiFz5bekMjHUxOme+ZpaskOajBXf51dfUT3f 01ni9zd8TVCPjbKlxw0dDnBMO+JFqFuvoNzDxj7xdA2csddHoUElvxu6HfHDXP/y 1NogbFAVVTKvjpwDahTuCH0hpeN1UNJ5nNtd3H8LPqLkOQnPQz9gPmyubCC54YXd IeS+0fc8MDs/veTVWg2yLtufhLf6pE6tFImEtYPy8QuV0vV15DhdoLHTmNQBgr+K u7jaa/DpVLRiw41QwdU96wXG7oo0icPy+UsRW5ok3qTTm1Qb5ILhjtg7BBNs02If CJAwSDSU3+aA2Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfedtgdduheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugfgjgesthekre dttddtjeenucfhrhhomheptehlvhgrrhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgv segrlhhvhhdrnhhoqdhiphdrohhrgheqnecuggftrfgrthhtvghrnhepudejveejffejve duudetvdekieeuiedtvdeileefkeevjedufeeguedvjefhueelnecuffhomhgrihhnpegv nhhtvghrphhrihhsvggusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 19 Jul 2021 17:24:52 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id B6E4F2A0803; Mon, 19 Jul 2021 17:24:48 -0400 (-04) Date: Mon, 19 Jul 2021 17:24:48 -0400 From: Alvaro Herrera To: Kyotaro Horiguchi Cc: jeff.janes@gmail.com, mk@071.ovh, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17103: WAL segments are not removed after exceeding max_slot_wal_keep_size Message-ID: <202107192124.kay2nglie2y3@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210719.111318.2042379313472032754.horikyota.ntt@gmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Jul-19, Kyotaro Horiguchi wrote: > Sorry for the mistake. It seems to me the cause the above is that > segment removal happens *after* invalidation. Since (at least > currently) the "slot is invalidated" warning issued only at the time > just before WAL-removal, we should expect that old segments are gone > after the checkpoint-ending log, which should be seen after > WAL-removal. If not, that shows that there's a bug. > > What do you think about the attached? Sounds sensible -- I verified the logs for one of the cases that failed in the buildfarm, and indeed the "checkpoint ended" message appears after the s2 slot is created, so it should fix the problem. (I didn't actually try to reproduce the problem locally, so I didn't verify the fix any further than ensuring the test still passes.) Pushed, thanks! -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/