Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u1FTa-00GbS4-1E for pgsql-hackers@arkaria.postgresql.org; Sun, 06 Apr 2025 02:11:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1u1FSY-006MSd-D8 for pgsql-hackers@arkaria.postgresql.org; Sun, 06 Apr 2025 02:10:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u1FSX-006MSU-Rd for pgsql-hackers@lists.postgresql.org; Sun, 06 Apr 2025 02:10:06 +0000 Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u1FSV-003dr3-12 for pgsql-hackers@postgresql.org; Sun, 06 Apr 2025 02:10:05 +0000 Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-2241053582dso41957295ad.1 for ; Sat, 05 Apr 2025 19:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1743905401; x=1744510201; darn=postgresql.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=SXlyeqhJ7Seu+RSpRkSGGRmT2YTxAqQEqX9QXz9C1as=; b=HASA2Qv0DH+MXxfE8zD1UuYdj8048GC001NPSLo1nUwwaa4TzlyNqKDE06eWaUGs49 WeJINVXW/VmZ58yvWfoi/ckQMTtBKGF52cCcwEaCQIVnzNpEWawYpH6F42/YHIH7mBUk 95DN4ppNaZegt800tBhNoJCEsGxrFdavan5R8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743905401; x=1744510201; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SXlyeqhJ7Seu+RSpRkSGGRmT2YTxAqQEqX9QXz9C1as=; b=eotEgyNrvnJsccsB3uSZrnTGKedSaSxo7Mm4CGx4GAioWJM0+d5IUd6iLXu9Y0MNPQ Qa9p1MMeN9XBNSWCkrFs50iIs9T28+FsuAWrzKfW8r8dKU36Pw71sxDc/R2Kq4yaQG8a f/C7V4Jcny3DmwIxM0+EKqtrbKdkn7iZidfnh1EEnSOGscQ4o1TA6aesFk+V2IAPhXbp pjnFQIQ4vmy26YBXbrsM5A630m+4FHem2RBkQcY87VHTGcm1dRlXJhxnWlXihcl9rtTg rulbHedMwbfV7x4S9Idj5BART+ZJDZqfC6pK+OUDSmSr22oQzl6K4BA8TdtE5YYsS5H+ kWpg== X-Forwarded-Encrypted: i=1; AJvYcCU5OQMcDnMdBypYjcXopFszOFeh8RgFs5hZ2TuyJOfOszKfVcJAyWdOkjtADvtbybTi4G4xR5KkoqVI2Elm@postgresql.org X-Gm-Message-State: AOJu0YxvHpFetgCCTKRlz/2oNAOBkBRvBdyUXTleMjhnvkzxZKdNAC1G d1WwiaVWgSrgmS6j0hyGBO9n66CRBHemI4Vdz9Rli08gyblPdRNp4Vd9gR6A9w== X-Gm-Gg: ASbGncsdXWpSBXmB/x5/1UXPSYqPR6jsQcOdF6JaRIoTXiKwOFbU0cahKtjU9x+EyM9 9ryn850JYqgr9NPY2bN3ldnLMMU+cjx6aw1kOP5soUhjOrWidM6EClwMmZZyrPcOfJdUxJQ8SuQ E9BhV3P5R2IBNcaBSrIpAJajvYLNfWG7kowJVw4F21KUkrvZnvXHe7M/keHH4Oz03UNa7e+OxMD V+wS9mGtFLeU50X7ONggzuYJdhiTXAqJzFvFTWEc319Y2OyDlTYhN4W3Mh0m43bn2R6ANYxm0Pl vXZejyoigAj7BlyTrxLAvYjuJIYX+x9td13/JUq4PM3mM8ynUxYi X-Google-Smtp-Source: AGHT+IG+WqQ1btMTIPGpC/DplIXNLMUunTLwPXJ+P6C+i1Em0hT5cTdbtUDE6nwxhsqLF3GQy4Kwrw== X-Received: by 2002:a17:902:e5cf:b0:223:517a:d2e2 with SMTP id d9443c01a7336-22a8a0b4149mr122488275ad.53.1743905400850; Sat, 05 Apr 2025 19:10:00 -0700 (PDT) Received: from google.com ([2601:647:5600:80d0::31cd]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-229787726f5sm56046655ad.217.2025.04.05.19.09.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Apr 2025 19:10:00 -0700 (PDT) Date: Sat, 5 Apr 2025 19:09:58 -0700 From: Noah Misch To: Michael Paquier Cc: Tom Lane , Nathan Bossart , Andres Freund , Robert Pang , Kyotaro Horiguchi , 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: <20250406020958.95.nmisch@google.com> References: <20250311205749.a8.nmisch@google.com> <20250312012315.fd.nmisch@google.com> <20250403002900.5d.nmisch@google.com> <2461391.1743865633@sss.pgh.pa.us> <20250405191339.8d.nmisch@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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.)