On Thu, Oct 08, 2026 at 09:32:30PM +0100, Zsolt Parragi wrote: > I did extensive local testing, and I was able to reproduce the > walreceiver failure with both 29992a6a509 and a8458f508a7 reverted, > but not with only reverting 29992a6a509.
Okay, noted. Did you run some of the in-core TAP tests locally or did something else? Could it make sense to stress the CI a few times without a8458f508a7a, with the two unstable tests, with one of your earlier tricks to increase the reproduction rate and confirm that a failure shows up? Then repeat the same process with a8458f508a7a and confirm that the problems are gone? The point is to be able to test on my end and confirm manually your report, and be able to do that without me having to spin a WIN32 environment just for this purpose. :) > Based on this, and the earlier discussion already in [1], I think we > should try reverting e0f633ca6bc (the windows specific test fix) and > 29992a6a509 (the revert of the proper fix) on master, so that we can > watch the buildfarm and see if my analysis is correct. > > The attached patches are simple clean reverts of these two commits. Perhaps merging both of them together makes the most sense, so as we never finish with a point in the tree where a failure shows up. Or just reverse the order of your v1-0001 and your v1-0002 if both things are not merged together. -- Michael
signature.asc
Description: PGP signature
