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 1m8Y0U-0001RR-LY for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Jul 2021 01:05:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m8Y0T-00087O-KJ for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Jul 2021 01:05:09 +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 1m8Y0S-00087G-Of for pgsql-hackers@lists.postgresql.org; Wed, 28 Jul 2021 01:05:09 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m8Y0P-0000uE-Qb for pgsql-hackers@postgresql.org; Wed, 28 Jul 2021 01:05:07 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9ECA25C01B5; Tue, 27 Jul 2021 21:05:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 27 Jul 2021 21:05:04 -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=J+2xyyqGtQ/9FkytRUxbCybirp+o6qycwhVt/v5HC38=; b=J8LfKD0l jaKol0VlFc3y4ZFs2p6S73ov6gbFK2AhWkGQYauq1L0+4b2bPQ//JTJIfZJYVqH4 lr/nUruE4r4dYu/1DaaQNHIERmGmPsod9SkPoiadhekthj6PiRmKNeYKt31x0tK8 IM+QxuKwPCyrPfs3tzoj7n1h7L1k0JcyteJzsNQUMpvZgjgiCmU8MDCGRTMBxKdp sfR+bv0Ai2wG+F/h/VBUhV3Yk+0PkFFritwvEbkB9+WhfqZcv1qfpUInof6Q9jzs 3Tl/tu8UgO3FS2dUF2PmsnL0sDiMRhzuS9WB4OCaQ8WsIvdrIGuUxxhx55KTkwUY +NuAMri7O02wzA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeekgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgrrhho ucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgheqne cuggftrfgrthhtvghrnhepudejveejffejveduudetvdekieeuiedtvdeileefkeevjedu feeguedvjefhueelnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomhenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgv rhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 27 Jul 2021 21:05:02 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 63C6E2A087C; Tue, 27 Jul 2021 21:04:58 -0400 (-04) Date: Tue, 27 Jul 2021 21:04:58 -0400 From: Alvaro Herrera To: "Bossart, Nathan" Cc: 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: <202107280104.ah3afb7d3grg@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <593A8B65-507E-4C53-9076-5420E429F03B@amazon.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Feb-19, Bossart, Nathan wrote: > 0002 adds logic for persisting the last notified segment through > crashes. This is needed because a poorly-timed crash could otherwise > cause us to skip marking segments as ready-for-archival altogether. > This file is only used for primary servers, as there exists a separate > code path for marking segments as ready-for-archive for standbys. I'm not sure I understand what's the reason not to store this value in pg_control; I feel like I'm missing something. Can you please explain? There were some comments earlier in the thread about the maximum size of a record. As I recall, you can have records of arbitrary size if you have COMMIT with a large number of relation invalidation messages being included in the xlog record, or a large number of XIDs of subtransactions in the transaction. Spanning several segments is possible, AFAIU. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "La rebeldía es la virtud original del hombre" (Arthur Schopenhauer)