Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nBnzl-0005Nv-Aj for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Jan 2022 01:18:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nBnzj-00042N-F4 for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Jan 2022 01:18:07 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nBnzj-00042E-62 for pgsql-hackers@lists.postgresql.org; Mon, 24 Jan 2022 01:18:07 +0000 Received: from mail-ot1-x335.google.com ([2607:f8b0:4864:20::335]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nBnzg-0002WU-En for pgsql-hackers@lists.postgresql.org; Mon, 24 Jan 2022 01:18:06 +0000 Received: by mail-ot1-x335.google.com with SMTP id s6-20020a0568301e0600b0059ea5472c98so4447485otr.11 for ; Sun, 23 Jan 2022 17:18:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=K+CedtV2B9DooftQphZD5fXCJn273qoV2GcJ3ochm2g=; b=eOwjVQ64+S3oCcOQfHTrRvhfx3K5uqFSk3mbPoAwb2XpokuSgr8fLalzUG7IxqMMkh 0ZyiwAGL0ZSsa4IW6PFDUZLSgvWJk3QyMIZHInN31YVguJz7CbHLM2PVFE5oEVfWNT6p iLQAJ/eEVHeupGNGRfVW5tYMdhaJWUW8d/7Tk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=K+CedtV2B9DooftQphZD5fXCJn273qoV2GcJ3ochm2g=; b=r9zvt9nYJW9M2DRX/1bMC4neo+UQQ/o3Gqdei/mid6E9sC2eiWZjirLDhO0ZI20Lxx f49ClgU6FEAnSf25qF6FETq3ukQMrdHpE4r3W0Uj9oeZ1ExOPNc0DNwFfJmi5n9ySS4U p7ACumsWwKFsjKOuuPEu03DiHSTy98PAtzoyvZM3eyYPAv4Bl8WF4sEMDc2APqY9DIXU VsCn/i5Xih5owmPbK2NJhGuTZ3wZbSBeLDCweG1B1MutjvqxUevr1TkR9qtdXe+a+FBg 3UvC+GmWGc7jQYedBEVXmFgI2baoPo3VmS2XXek8KVFejHt6PoMGBVjUONTgW6/oBurJ 2G9g== X-Gm-Message-State: AOAM530Q4FxZigVGn8BLFyiK+ORUaCQK1JZHyhfJr8MIxnS6l7fvmqiL ebV6OazPU9vfwce4BFTxdm4QQQ== X-Google-Smtp-Source: ABdhPJw3ZlNpRjW3tHMhLqAOG540Oz1P2A0fld8+XuyizCdFeLiXO8LiNf2Al9souwiVHyalT0wuyQ== X-Received: by 2002:a05:6830:22f7:: with SMTP id t23mr9680324otc.213.1642987083333; Sun, 23 Jan 2022 17:18:03 -0800 (PST) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id f2sm4968440oiw.50.2022.01.23.17.18.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Jan 2022 17:18:02 -0800 (PST) Date: Sun, 23 Jan 2022 17:17:59 -0800 From: Noah Misch To: Andres Freund Cc: pgsql-hackers@lists.postgresql.org, Thomas Munro , pgbf@twiska.com, Tom Lane , Michael Paquier , pgsql-hackers Subject: Re: XLogReadRecord() error in XlogReadTwoPhaseData() Message-ID: <20220124011759.GC1131882@rfd.leadboat.com> References: <2782601.1637189230@sss.pgh.pa.us> <20211118070506.GA1294133@rfd.leadboat.com> <20211120051823.GA1367142@rfd.leadboat.com> <20220116071210.GA735692@rfd.leadboat.com> <20220116210241.GC756210@rfd.leadboat.com> <20220122185241.GA1095169@rfd.leadboat.com> <20220123232927.GA1131882@rfd.leadboat.com> <78685FA0-EEC6-4AFB-B323-C37A99C82563@anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78685FA0-EEC6-4AFB-B323-C37A99C82563@anarazel.de> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Jan 23, 2022 at 05:03:04PM -0800, Andres Freund wrote: > On January 23, 2022 3:29:27 PM PST > >(a) Modify the tests so the affected animals can skip affected tests by > >setting an environment variable, named PG_TEST_HAS_WAL_READ_BUG or similar. > > Why not just detect the problem in the tap test and skip, rather than requiring multiple buildfarm configs to be changed as well as the test itself? End users running PostgreSQL test suites to acceptance-test their stack should consider the affected stack unusable for PostgreSQL. Hence, I ruled out that approach, despite having implemented it at one point. Under some plausible set of goals, it is optimal.