Re: A failure in 031_recovery_conflict.pl on Debian/s390x

On Tue, Aug 29, 2023 at 1:58 AM Christoph Berg <myon(at)debian(dot)org> wrote:
> This should be fixed before the 16 release.

Here's what I was thinking of doing for this, given where we are in
the release schedule:

* commit the signal-refactoring patch in master only
* plan to back-patch it into 16 in a later point release (it's much
harder to back-patch further than that)
* look into what we can do to suppress the offending test for 16 in the meantime

But looking into that just now, I am curious about something. The
whole area of recovery conflicts has been buggy forever, and the tests
were only developed fairly recently by Melanie and Andres (April
2022), and then backpatched to all releases. They were disabled again
in release branches 10-14 (discussion at
https://postgr.es/m/3447060.1652032749@sss.pgh.pa.us):

+plan skip_all => "disabled until after minor releases, due to instability";

Now your mainframe build bot is regularly failing for whatever timing
reason, in 16 and master. That's quite useful because your tests have
made us or at least me a lot more confident that the fix is good (one
of the reasons progress has been slow is that failures in CI and BF
were pretty rare and hard to analyse). But... I wonder why it isn't
failing for you in 15? Are you able to check if it ever has? I
suppose we could go and do the "disabled due to instability" thing in
15 and 16, and then later we'll un-disable it in 16 when we back-patch
the fix into it.