Re: Back-patch of: avoid multiple hard links to same WAL file after a crash

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

In response to

Responses

Browse pgsql-hackers by date

  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)