On Tue, Aug 29, 2023 at 1:58 AM Christoph Berg <m...@debian.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.1652032...@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.
