On Wed, Sep 30, 2026 at 05:31:53AM -0700, Zsolt Parragi wrote:
> I agree with the let's try the revert on master approach. That won't
> help with random failures on the stable branches, but at least we are
> aware why it is happening now, and later we can either apply the
> revert on them, or disable these tests on them, or apply v3.
It would mean that the spurious failures would still be annoying on
stable branches while we evaluate the HEAD case. See below.
> The question is, what would be good enough proof? I can reproduce the
> walreceiver issue with around 1% failure rate on my laptop, and it
> didn't reproduce even once with only reverting 29992a6a509b in more
> than 5000 runs.
> I'll try to do the same thing on back branches, and I'll also set it
> up on github actions to test it there.
How about the following plan, instead? I would suggest moving forward
with the following steps:
- First disable these tests on WIN32, backpatch this change to
entirely silence the buildfarm. I am not really sure that we gain
much coverage by keeping them while the non-WIN32 paths would still
stress the cases in a stable manner. In order to do that, some
Makefile and meson.build can be manipulated to make the tests
conditional depending on the platform, something that we already do
that. One small-ish issue here is temp-schema-cleanup in
src/test/isolation/. Let's just move that to test_misc, I guess
(cannot think of a better location), create an ISOLATION target list
in a conditional manner.
- Revert the revert on HEAD, allow the tests to work on WIN32.
- Monitor the result for a few days or weeks. Investigate if more
actions are required and what to do in stable branches, and if we
actually want to do something in stable branches. My gut feeling is
that we'd do that only on HEAD, this has been reverted a lot already.
The meson and Makefile tricks already exist in the tree:
* For meson "if host_system == 'windows'".
* For Makefile, that should be "ifeq ($(PORTNAME), win32)".
This plan is risk-free: even if step 1 is reverted, we still have the
benefit of not running these unstable tests on WIN32, keeping the
buildfarm stable in the long run anyway.
So, thoughts?
--
Michael
