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.
