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 1njbo0-0006CF-2B for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Apr 2022 07:09:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1njbnx-00010H-6I for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Apr 2022 07:09:41 +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 1njbnv-0000z2-HT for pgsql-hackers@lists.postgresql.org; Wed, 27 Apr 2022 07:09:40 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1njbnl-0003hz-Vk for pgsql-hackers@postgresql.org; Wed, 27 Apr 2022 07:09:37 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 5D3A65C0118; Wed, 27 Apr 2022 03:09:26 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 27 Apr 2022 03:09:26 -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=fm1; t=1651043366; x=1651129766; bh=ZUSqI9Agnk Z7zx6ip8r9t6FLSE3Syj9+sPnVLrIjiN4=; b=pMB/pV1tbW0ElI+054Ett3GSSC UQs6XFCq9Ou83qbSdFgLlobpLJYyoBUvqrm0NZhjFNUEQfWgP+pPLXErzy4/Me1a j/I3ezLQa0qpfkGnJMTIkhkiSp+83hKsoCBCZf4SmYNM4CY8wjCjByvNE2OE9+Oe 8j/6ByXKgqXPCyqM0cCWTDA/pOWlNLVHKUBgLljWVCtc9Em5c1ssYWvjPxEzUiuB nOII+Q7d6j75Uzju++RMhNoQfNKdp3sjUMFcKbr1NCGgZBT+aaT8tPP87XfRHa84 PTKqEFXmdnVEOgjoB3JkmKeV3Zom4j2wkS5YQS1iHVKK5XHo4iFeSw1HHqXA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1651043366; x= 1651129766; bh=ZUSqI9AgnkZ7zx6ip8r9t6FLSE3Syj9+sPnVLrIjiN4=; b=j wHPNsYG5rWRbYOPLKGKo4CZRQfa9qG42HUlLRLeEU42+791SxLbvd78b0PkF7jV1 3oqo/gG4ubcVCU1IDOL+5u6qYwuvuc8b2rQeJKono61NDfj6cDEbQd06dCrPaudz rAalVCCB+SJ+yAF4McZ89x66hs0D8Qmsnqkk3TxfOL9Nwvd2laQExWfkolE93Ced PyfeIX0HN1C8DQDFgTtOVWlfCFFsi2f0qSmUp9Yn8ltGzbnhMOSuRNm2XH9y7ywX F5RZ/4R+734wZqYUkVQ9GMlMbI5WJnvFGDaTXKtrZYUyWl4SsQqUtMHCyc/pscr9 GdmnGDkw+fQT3dXtBneeA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeggdduuddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdljedtmdenucfjughrpeffhffvvefukfhfgggtuggjsehgtderredt tddvnecuhfhrohhmpefoihgthhgrvghlucfrrghquhhivghruceomhhitghhrggvlhesph grqhhuihgvrhdrgiihiieqnecuggftrfgrthhtvghrnhepteelieefudffhffhtdetleeg geegfffhkeeuveetiefgudduvedutefggeeivdejnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhhitghhrggvlhesphgrqhhuihgvrhdrgiih ii X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 27 Apr 2022 03:09:24 -0400 (EDT) Date: Wed, 27 Apr 2022 16:09:20 +0900 From: Michael Paquier To: Nathan Bossart Cc: Greg Stark , Tom Lane , Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: avoid multiple hard links to same WAL file after a crash Message-ID: References: <20220407182954.GA1231544@nathanxps13> <20220408165312.GB1409034@nathanxps13> <2370127.1650308835@sss.pgh.pa.us> <20220426200935.GA3175655@nathanxps13> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jhevKCbYrejNZCLR" Content-Disposition: inline In-Reply-To: <20220426200935.GA3175655@nathanxps13> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --jhevKCbYrejNZCLR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 26, 2022 at 01:09:35PM -0700, Nathan Bossart wrote: > Here is an attempt at creating something that can be back-patched. 0001 > simply replaces calls to durable_rename_excl() with durable_rename() and is > intended to be back-patched. 0002 removes the definition of > durable_rename_excl() and is _not_ intended for back-patching. I imagine > 0002 will need to be held back for v16devel. I would not mind applying 0002 on HEAD now to avoid more uses of this API, and I can get behind 0001 after thinking more about it. > I think back-patching 0001 will encounter a couple of small obstacles. For > example, the call in basic_archive won't exist on most of the > back-branches, and durable_rename_excl() was named durable_link_or_rename() > before v13. I don't mind producing a patch for each back-branch if needed. I am not sure that have any need to backpatch this change based on the unlikeliness of the problem, TBH. One thing that is itching me a bit, like Robert upthread, is that we don't check anymore that the newfile does not exist in the code paths because we never expect one. It is possible to use stat() for that. But access() within a simple assertion would be simpler? Say something like: Assert(access(path, F_OK) != 0 && errno == ENOENT); The case for basic_archive is limited as the comment of the patch states, but that would be helpful for the two calls in timeline.c and the one in xlog.c in the long-term. And this has no need to be part of fd.c, this can be added before the durable_rename() calls. What do you think? -- Michael --jhevKCbYrejNZCLR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmJo7CAACgkQnvQgOdby QH0+kRAAk4vj1B7Zy4IZ2LGHIKPHqOB1q3S6q7vpR4ZT9IZDqEfm3oj0qzq8+RFV oIBL9Llz/Vo0M54vAFxrAptUyezDhOqRW/tl8VQQMdpeilWKwyVNOid/iHHI+H53 0LCm67ACvEd2yALSBsjQj6iW2Z2Lk49wiy3gYugTKRfJRqJMKYQi6Ck/JXC/uxoe ocxehGlCDh+8lQYjFNVBTbOqQLCkAzMOaGKOI5yAJ2e5LNkKR0d/0wSD+xBvpzet TwaflVTHqocLycHDdUq6cVSbqLij8AiMVB3ZxuImZhILNFcsTlVEWQSXFDhNuTy1 m/486djCoowYv9CBbbDH56Rc4yJ7FZHMF/YVb3AwCco/m7sP+IIxAgnQglUSPwah 8MjkLjwPN+Y7CFbUew0dHLKluBZE+yEM4Fi58hOqZ9au4eE/F+lGAfrb5sySys/9 tXkJ1Pwh4mbTukqgMEhvlkmVA9JfzWeODPG4TCRYNcQeNrJlxhY5QVTz3yYFkFNT QrTn4HA7YkPwbgp7I9sirJPasvUmNvwW+tSaD/tsFyWrInlNEG2LiExOZrNYtKuB zoej+FM7ZlMXCy+WaR8W7asI5bT/TaPy0aQSzjroKXaIpKkqQbtFCyPdM4kRtGVM YwwPuJUVX3nvQHeNkdPF79gjsYDdC2pTZdKpz+efNje3IynpnA4= =0SYO -----END PGP SIGNATURE----- --jhevKCbYrejNZCLR--