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 1o8XET-0004xC-0R for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Jul 2022 01:20:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o8XER-0003VQ-UB for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Jul 2022 01:20:03 +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 1o8XER-0003VH-42 for pgsql-hackers@lists.postgresql.org; Tue, 05 Jul 2022 01:20:03 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o8XEK-0000tu-EM for pgsql-hackers@postgresql.org; Tue, 05 Jul 2022 01:20:02 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 90906320092F; Mon, 4 Jul 2022 21:19:54 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 04 Jul 2022 21:19:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= cc:cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1656983994; x=1657070394; bh=lqwF0qjfDu PtPqYtrxB2lM9nqcc1Ti75aoW++NWoNO4=; b=bBpBkwYEBqjVnF/lwfHVoybc9q lfWdo6FEnsmgdEYuSGGD+Cu6OYmcSuYz4PxF9eRRNxHEkAAm2EPXFkRZiB0QCpsh vuMVDoOt9S0VQONXiWhMMWcY7TMFJBxOUfojgKTtq4xfidz4I4KYipulbUhKIQ1S KZZJU4JahxFAm3tx+UdyHnZl1k4K7oRi0LR8RaDnSj97wUXb1P4u19bs1MBstTzQ mEWT2xza+t4J2YmWbo4O74esoaNhzlhgyeqdFfLBPLL4GlIl+By+szFanHbkYYdv s3ftFGQpU8IPI/NOtbFGzXfF/Wj86626vSpTV7HdUg1hbSmL01yAkm7vacFw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1656983994; x=1657070394; bh=lqwF0qjfDuPtPqYtrxB2lM9nqcc1 Ti75aoW++NWoNO4=; b=L/9bzzoDQvK3z0k1nQ/1PwQ9xIEemUFvRJr4hzZqq8ZE ePYK+fMN9FLRJzMZtQ1OsoMAhkhaDJaeghhOPibvBdp5thUPmObc7wS1AekM8xNB B2T9atIjyeLHulvG5F7XA6PzENdIqNfHPd8nNWBk7Q78ZMrYOHug5wwvdMOZxr22 yAGVvoAhvMDA58l5EwvaDub/cd1et0VoXdGgXy0VDxLFjWgiiI4bU6ky23L8I2/f GWFUFP0JLQGxzUVgigE/Ghjwg9Dt2p97Lq570i2o6d88peWOjiCqR0VjqAAt+zfw GbA0fH4Nqm56AGjWbVZft+lcHtQVZpfXzA/UbNS0uA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeitddggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdljedtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredt tddvnecuhfhrohhmpefoihgthhgrvghlucfrrghquhhivghruceomhhitghhrggvlhesph grqhhuihgvrhdrgiihiieqnecuggftrfgrthhtvghrnhepteelieefudffhffhtdetleeg geegfffhkeeuveetiefgudduvedutefggeeivdejnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhhitghhrggvlhesphgrqhhuihgvrhdrgiih ii X-ME-Proxy: Feedback-ID: i0fe9450f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 4 Jul 2022 21:19:51 -0400 (EDT) Date: Tue, 5 Jul 2022 10:19:49 +0900 From: Michael Paquier To: Nathan Bossart Cc: Kyotaro Horiguchi , tgl@sss.pgh.pa.us, robertmhaas@gmail.com, pgsql-hackers@postgresql.org Subject: Re: avoid multiple hard links to same WAL file after a crash Message-ID: References: <289699.1649694527@sss.pgh.pa.us> <20220411165257.GB1915258@nathanxps13> <20220412.154631.417529439388886590.horikyota.ntt@gmail.com> <20220412162742.GB2062175@nathanxps13> <20220502173907.GB3351307@nathanxps13> <20220502230613.GA3398932@nathanxps13> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aJRhL/IitTvIVRST" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --aJRhL/IitTvIVRST Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 05, 2022 at 08:10:02PM +0900, Michael Paquier wrote: > I'd agree with removing all the callers at the end. pgrename() is > quite robust on Windows, but I'd keep the two checks in > writeTimeLineHistory(), as the logic around findNewestTimeLine() would > consider a past TLI history file as in-use even if we have a crash > just after the file got created in the same path by the same standby, > and the WAL segment init part. Your patch does that. As v16 is now open for business, I have revisited this change and applied 0001 to change all the callers (aka removal of the assertion for the WAL receiver when it overwrites a TLI history file). The commit log includes details about the reasoning of all the areas changed, for clarity, as of the WAL recycling part, the TLI history file part and basic_archive.=20 -- Michael --aJRhL/IitTvIVRST Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmLDkbUACgkQnvQgOdby QH3Aig//cnJh97NNnondEn9yfqZ9qwaJeoTFpgg7942TKETXnEsfeOOmBaZjIe2U UyKHenog9Mcejh4E6qapCtRt4q31a6MhyzqEhQ43ylXOzrDJIXC8ty+mwg3ttlZN LidrcwGG6tA8xOCzXotuHAi5yZE/Y8DDNr98CTn4PESQwVMU2Ga/XWmalt+ixaK5 RwqJzaJQd4ywQCgmoXmIwe1NIGcQN2/f6OreDUmS6CpkF2q/OWshA9aRrY2P+8y5 vwoHmcdEUPJhcSBwLG9uuktsHSI5OZcZqE+ztFsDKkUL2acKQRt37e5Qo0CtYhHW yIlvofyUevDYMIcSdhVgjnG3CagBFOl7HcAh8QHM1cmTU6OytC/VfwRFhrv2MSnY ItcSfP4RkyM0/mZNTYDoMiA750d90FPa8m86SV+q/bQl2QWQKMBJTEUlv+aeI8C2 OessH5c0h4UGBqMuYdTG7vo4e3kkdTwvgTlIcqPjSPUcK/mby03e62ZWmtoQOBzI Ag9UzXSedLj9Q+ZDAm0t2cbwW18uCEZUc3fmGcJloiUMdV3QL0+JHSbDBppYNHAT caSXt/cXKH9gNgeJ7VQsiLWSAFXkictWJTp6eWQXCI32AQM6V4feVSNT9Xw4vZAY VbNK6w6r1Scf6+rhz3Tomq2kkFGllRUCMNQzuUZZHl58kXihQcU= =nGOO -----END PGP SIGNATURE----- --aJRhL/IitTvIVRST--