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 1mIDWh-0005B6-9s for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Aug 2021 17:14:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mIDWf-0001Le-T3 for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Aug 2021 17:14:21 +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 1mIDWe-0001LV-UT for pgsql-hackers@lists.postgresql.org; Mon, 23 Aug 2021 17:14:21 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mIDWb-0004qa-1a for pgsql-hackers@postgresql.org; Mon, 23 Aug 2021 17:14:20 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2FA1C5C0153; Mon, 23 Aug 2021 13:14:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 23 Aug 2021 13:14:15 -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=GGe6QT2+cV9DFTXH/WXQEzm93ntiDWAcBTy9nl+g0gI=; b=BXalcbHp T8WKfep9/lcD/DiTZPakZXqXBeVIYA2x1tID9PCKNI6jjbQmmGGC53+RzTeVjRX3 1yOFvLSfjpt/vwW23m0R7Z5XQ4TYva4ODH1cV+unVOdoCKa5bKtlEq/jT9TE5Bgz /k5MHhSyc0MXBq/chdtk3vFMn8Q9dnMQZSZzxcPxPxD0HWGzxKdKW1npHFoaqOcC ZtwgV4WPgpHAMYSRjEIn2XPuH61N9799YOtiUedWfp5R1JvjU8JICDko+EtNQaBR 2VSRAJH37jkJKiXW0XiZmOWzaVymGuE2gGy6rQjoO08yg/evrDfd7uFY1PjrrELs z8NxRrgeH95O5w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddthedgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomhepfdgrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgfdcuoegrlhhvhhgvrhhrvgesrghlvh hhrdhnohdqihhprdhorhhgqeenucggtffrrghtthgvrhhnpefhudeftdfhleevgeejtdff udelkeeiudfgtdfgtddtveetjeelteeghfeuiefgteenucffohhmrghinhepvghnthgvrh hprhhishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 23 Aug 2021 13:14:12 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id C7C482A0284; Mon, 23 Aug 2021 13:14:09 -0400 (-04) Date: Mon, 23 Aug 2021 13:14:09 -0400 From: "alvherre@alvh.no-ip.org" To: "Bossart, Nathan" Cc: Robert Haas , Kyotaro Horiguchi , "x4mmm@yandex-team.ru" , "a.lubennikova@postgrespro.ru" , "hlinnaka@iki.fi" , "matsumura.ryo@fujitsu.com" , "masao.fujii@gmail.com" , "pgsql-hackers@postgresql.org" Subject: Re: archive status ".ready" files may be created too early Message-ID: <202108231714.kdyudmc5aojp@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4268438D-343C-4831-8511-17B03CEA028E@amazon.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Aug-23, Bossart, Nathan wrote: > Sorry, I'm still not following this one. If we skipped creating > .ready segments due to a crash, we rely on RemoveOldXlogFiles() to > create them as needed in the end-of-recovery checkpoint. If a record > fits perfectly in the end of a segment, we'll still register it as a > boundary for the next segment (hence why we use XLByteToSeg() instead > of XLByteToPrevSeg()). If database activity stops completely, there > shouldn't be anything to mark ready. The only way .ready files are created is that XLogNotifyWrite() is called. For regular WAL files during regular operation, that only happens in XLogNotifyWriteSeg(). That, in turn, only happens in NotifySegmentsReadyForArchive(). But if the system runs and never writes WAL records that cross WAL boundaries, that function will see that both earliestSegBoundary and latestSegBoundary are MaxXLogSegno, and return without doing anything. So no segments will be notified. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/