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 1m9XK5-0006m5-98 for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Jul 2021 18:33:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m9XK3-00058D-MW for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Jul 2021 18:33:27 +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 1m9XK2-000585-QM for pgsql-hackers@lists.postgresql.org; Fri, 30 Jul 2021 18:33:27 +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 1m9XK0-0007TK-81 for pgsql-hackers@postgresql.org; Fri, 30 Jul 2021 18:33:25 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id E93DA5C00E1; Fri, 30 Jul 2021 14:33:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 30 Jul 2021 14:33:22 -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=cjA9HfL3vrVQBxu68wmDLG/hd1Qb4P/W/eGjhqFqZA8=; b=BJYIMRkh jOzw76WTW6kemCY6+Ti8lUFF5Ridb5GPJ1++HtTYnB2qAcl7c7jQL9B7T8SDyUzM b8+n44v6ZGfHGV4E6PKVoiz0h9RriiWuNtDxagXjE0uDhZejcmCBWThzLnQ+G2zG /yVTgqVpU39thJs/gwAY7E8WAbFvkNIg7gnsze80u5FTyoODpmef+WRiosXXWRiU QAyu0aEzRAjqKuyWJ3KmNPaDZrW6UXiK5tlUm5TCxZyH65nrLMjz4D9S22c5wB2o xCfYrofNJ5a8mZpWLjZZ/EBMTUVSTv3MJd36TA6skIE5AXy2532jxsCmbltgn3RR JRWEGEMCQ6tMlg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheehgdduudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 30 Jul 2021 14:33:20 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 8AD7B2A092C; Fri, 30 Jul 2021 14:33:15 -0400 (-04) Date: Fri, 30 Jul 2021 14:33:15 -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: <202107301833.7lyjghlns3hb@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Jul-28, Bossart, Nathan wrote: > On 7/27/21, 6:05 PM, "Alvaro Herrera" wrote: > > 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? > > Thanks for taking a look. > > The only reason I can think of is that it could make back-patching > difficult. I don't mind working on a version of the patch that uses > pg_control. Back-patching this fix might be a stretch, anyway. Hmm ... I'm not sure we're prepared to backpatch this kind of change. It seems a bit too disruptive to how replay works. I think patch we should be focusing solely on patch 0001 to surgically fix the precise bug you see. Does patch 0002 exist because you think that a system with only 0001 will not correctly deal with a crash at the right time? Now, the reason I'm looking at this patch series is that we're seeing a related problem with walsender/walreceiver, which apparently are capable of creating a file in the replica that ends up not existing in the primary after a crash, for a reason closely related to what you describe for WAL archival. I'm not sure what is going on just yet, so I'm not going to try and explain because I'm likely to get it wrong. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/