From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Robert Pang <robertpang(at)google(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Back-patch of: avoid multiple hard links to same WAL file after a crash |
Date: | 2025-03-06 19:44:30 |
Message-ID: | Z8n7HopB0bb4_j19@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 06, 2025 at 11:30:13AM -0800, Noah Misch wrote:
> Options I see:
>
> 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.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-03-06 19:47:08 | Re: Statistics Import and Export |
Previous Message | Peter Geoghegan | 2025-03-06 19:34:58 | Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans) |