Date: Tue, 11 Mar 2025 13:57:49 -0700
From: Noah Misch <noah@leadboat.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
	Andres Freund <andres@anarazel.de>,
	Robert Pang <robertpang@google.com>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, robertmhaas@gmail.com,
	pgsql-hackers@postgresql.org
Subject: Re: Back-patch of: avoid multiple hard links to same WAL file after
 a crash
Message-ID: <20250311205749.a8.nmisch@google.com>
References: <20220502230613.GA3398932@nathanxps13>
 <YnOwioN/mo6k1Dtb@paquier.xyz>
 <YsORtfT4+fXj/i1V@paquier.xyz>
 <CAJhEC04tBkYPF4q2uS_rCytauvNEVqdBAzasBEokfceFhF=KDQ@mail.gmail.com>
 <Z2L6e1w-xABVTBRR@nathan>
 <7chjz7zeigbsbt7nim4cj6zryflzcpy2lgenas3yh7cpvwf3gb@m6cwqzlvfd6q>
 <Z2Oy1Z2nMVmTM5L5@paquier.xyz>
 <20250306193013.36.nmisch@google.com>
 <Z8n7HopB0bb4_j19@nathan>
 <Z853yPDh1xNWssD_@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Z853yPDh1xNWssD_@paquier.xyz>
User-Agent: Mutt/2.2.12 (2023-09-09)
Archived-At: 
 <https://www.postgresql.org/message-id/20250311205749.a8.nmisch%40google.com>
Precedence: bulk

On Mon, Mar 10, 2025 at 02:25:28PM +0900, Michael Paquier wrote:
> On Thu, Mar 06, 2025 at 01:44:30PM -0600, Nathan Bossart wrote:
> > On Thu, Mar 06, 2025 at 11:30:13AM -0800, Noah Misch wrote:
> >> 1. Make v14 and v13 skip WAL recycling and preallocation during archive
> >>    recovery, like newer branches do.  I think that means back-patching the six
> >>    commits cc2c7d6~4 cc2c7d6~3 cc2c7d6~2 cc2c7d6~1 cc2c7d6 e36cbef.
> >> 
> >> 2. Revert 1f95181b44c843729caaa688f74babe9403b5850 and its v13 counterpart.
> >>    Avoid multiple hard links by making durable_rename_excl() first rename
> >>    oldfile to a temporary name.  (I haven't thought this through in detail.
> >>    It may not suffice.)
> >> 
> >> I'm leaning toward (1) at least enough to see how messy the back-patch would
> >> be, since I don't like risks of designing old-branch-specific solutions when
> >> v15/v16/v17 have a proven solution.  What else should we be thinking about
> >> before deciding?
> > 
> > I agree with first attempting a back-patch.  All of this stuff is from
> > 2021-2022, so it's had time to bake and is IMHO lower risk.

> Could it be possible for you to double-check and also run
> more tests if your enviroments help?

Thanks for crafting back-branch versions.  I've queued a task to confirm I get
the same result.  There's a test case I'll polish, too.