On Mon, Jan 24, 2022 at 12:49:16PM +1300, Thomas Munro wrote: > On Mon, Jan 24, 2022 at 12:29 PM Noah Misch <n...@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?