Date: Sun, 23 Jan 2022 16:19:14 -0800
From: Noah Misch <noah@leadboat.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: pgbf@twiska.com, Tom Lane <tgl@sss.pgh.pa.us>,
	Michael Paquier <michael@paquier.xyz>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: XLogReadRecord() error in XlogReadTwoPhaseData()
Message-ID: <20220124001914.GB1131882@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>
 <CA+hUKGLoV=wYa301GWaQUb7zb4cNE4QLqnik_QbHe-=3kpp=Ew@mail.gmail.com>
 <20220116210241.GC756210@rfd.leadboat.com>
 <20220122185241.GA1095169@rfd.leadboat.com>
 <CA+hUKGLbtEfCMXA9H+W6R-FRS7yojs5TdfqbNdEetTa7pB4Khw@mail.gmail.com>
 <20220123232927.GA1131882@rfd.leadboat.com>
 <CA+hUKGJoPEHetHf_x3Z=Zc1eFfcZY2W44-1BGaTNZ0=SVJ-Zug@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+hUKGJoPEHetHf_x3Z=Zc1eFfcZY2W44-1BGaTNZ0=SVJ-Zug@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20220124001914.GB1131882%40rfd.leadboat.com>
Precedence: bulk

On Mon, Jan 24, 2022 at 12:49:16PM +1300, Thomas Munro wrote:
> On Mon, Jan 24, 2022 at 12:29 PM Noah Misch <noah@leadboat.com> wrote:
> > 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.
> 
> Trying out a new idea: what if we could tell the buildfarm website
> that a certain test is currently expected to fail for reasons we can't
> fix yet (configuration change needed but owner not responding, or
> bugfix from another project needed, etc)?  That could cause it to be
> displayed in a different shade of green, or grey, or whatever?  Other
> kinds of failures would still show as red.  Perhaps this would be
> configured with a file in a git repo that any committer can push to.

That would be a better capability to use if we had it, agreed.  Is it feasible
to acquire that capability soon enough?