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

From Noah Misch
Subject Re: Back-patch of: avoid multiple hard links to same WAL file after a crash
Date
Msg-id 20250406020958.95.nmisch@google.com
Whole thread Raw
In response to Re: Back-patch of: avoid multiple hard links to same WAL file after a crash  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Back-patch of: avoid multiple hard links to same WAL file after a crash
List pgsql-hackers
On Sun, Apr 06, 2025 at 07:42:02AM +0900, Michael Paquier wrote:
> On Sat, Apr 05, 2025 at 12:13:39PM -0700, Noah Misch wrote:
> > Since the 2025-02 releases made non-toy-size archive recoveries fail easily,
> > that's not enough.  If the proposed 3-second test is the wrong thing, what
> > instead?
> 
> I don't have a good idea about that in ~16, TBH, but I am sure to not
> be a fan of the low reproducibility rate of this test as proposed.
> It's not perfect, but as the design to fix the original race condition
> has been introduced in v15, why not begin with a test in 17~ using
> some injection points?

Two reasons:

a) The fix ended calls to the whole range of relevant code.  Hence, the
   injection point placement that would have been relevant before the fix
   isn't reached.  In other words, there's no right place for the injection
   point.  (The place for the injection point would be in durable_rename(), in
   the checkpointer.  After the fix, the checkpointer just doesn't call
   durable_rename().)

b) Stochastic tests catch defects beyond the specific one the test author
   targeted.  An injection point test is less likely to do that.  (That said,
   with reason (a), there's no known injection point test design to compete
   with the stochastic design.)



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] New predefined role pg_manage_extensions
Next
From: Andres Freund
Date:
Subject: Re: A modest proposal: make parser/rewriter/planner inputs read-only