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 1nBmIk-0001SK-NS for pgsql-hackers@arkaria.postgresql.org; Sun, 23 Jan 2022 23:29:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nBmIj-0001vy-Ge for pgsql-hackers@arkaria.postgresql.org; Sun, 23 Jan 2022 23:29:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nBmIi-0001vo-W5 for pgsql-hackers@lists.postgresql.org; Sun, 23 Jan 2022 23:29:37 +0000 Received: from mail-qk1-x734.google.com ([2607:f8b0:4864:20::734]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nBmIe-0005zq-Iv for pgsql-hackers@postgresql.org; Sun, 23 Jan 2022 23:29:36 +0000 Received: by mail-qk1-x734.google.com with SMTP id a21so18107853qkn.0 for ; Sun, 23 Jan 2022 15:29:32 -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=eeB4l1AmLZbXIBxa4G1WdY+yCFJEzVrWuu2wxU6mFRc=; b=L7ttTI5jgfm+oYBuZndksIKNZZNOD1+3jOWCsgefzq42OLNJ/tJ64yyso7qSxUKZFv D2w3SVXZYWlFrxJXD3elN9mORYFnt+4vHKrA/jFNl7WJ94PdiUpyInJFFcUf1LDpsguB n4YgopgtEP+sSzdDASp7rm2WeM6clshIn7P+s= 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=eeB4l1AmLZbXIBxa4G1WdY+yCFJEzVrWuu2wxU6mFRc=; b=zygeSEvLS7VeSDddAYzCYiIsr7FpwRSb0Cg91+jN9gqI/k9tBtaLuf05wnaKTH2rh5 OvhwSDKfAgIpZ0DXWPx97dgZrJPMmh5eouQNCfy267xcXHcYMCEkZK03MHGAtsNZZdBY IAV/f+UPw29+9u64wqbyS1AS52geyWYdv5m9DyCoYmdoKv6DqyNAnBd+UCramjm40DC3 aaEhB5cg9RuuwVf1sBTXCc/CoJ9dDHzRUhQ5PUH8JVJJCDCI8Dg21TlQG0PuJ422oXds sKlB1p/f1ETpO7erm6ptMXppMbJJ0ftIy0dlcvEVnUn0WxfQs+dM5vW7m7F2q3GiqjN6 4Yww== X-Gm-Message-State: AOAM532Wia5/fu5uboRIDXSIcicavWpiyvfB3mTvfgUeSzGitKQEOz/s 8G2GZjEIty+7Jl6PyxqauG4h2Q== X-Google-Smtp-Source: ABdhPJwlJpO7mTzyGhym87pCRY5BBtrdvkv+u6EWiiPtHpl0vOF0buc4SvZPV+FwEyMMPwAsDao+5w== X-Received: by 2002:a05:620a:240f:: with SMTP id d15mr9625409qkn.67.1642980570737; Sun, 23 Jan 2022 15:29:30 -0800 (PST) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id n12sm6171358qta.5.2022.01.23.15.29.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Jan 2022 15:29:30 -0800 (PST) Date: Sun, 23 Jan 2022 15:29:27 -0800 From: Noah Misch To: Thomas Munro Cc: pgbf@twiska.com, Tom Lane , Michael Paquier , pgsql-hackers Subject: Re: XLogReadRecord() error in XlogReadTwoPhaseData() Message-ID: <20220123232927.GA1131882@rfd.leadboat.com> References: <20211112012234.GA1020314@rfd.leadboat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon, Jan 24, 2022 at 09:42:13AM +1300, Thomas Munro wrote: > I'm less > sure it makes sense to do anything to support the presumed bogus > zeroes bug for (probably) no real users, especially before we've even > reported it and heard some analysis, for example acceptance that it's > broken and confirmation that this really is just a sparc problem. Got it. I've already done a bad thing leaving the buildfarm broken for three months, so I don't want to let the buildfarm wait for a kernel fix. These are the two main options I'm seeing now: (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. (b) Remove --enable-tap-tests from affected animals. Do you have a preference among those two or some other option that gets the buildfarm green on a predictable schedule? I somewhat prefer (a), since --enable-tap-tests is where most of the interesting buildfarm reports happen these days.