On Wed, Dec 4, 2024 at 11:23 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > Wow, what a lot of variations we have to handle with no coverage. I'm > coming around to your proposal Robert. We decide that it is OK to > back-patch freely, under a policy along the lines "we try to keep > stable branches working on the latest MinGW toolchain version only, as > a developer convenience". Even if it creates contradictions in > back-branches (using some stuff unguarded, even if other stuff is > guarded because it needed to be at the time). I'm not sure what > quorum is needed for such a decree, but from a verification point of > view, that's the effective reality already. An interested party would > need to show up with the resources to maintain another platform > variant; so yeah, why not let them do that, if something we back-patch > turns out to be a real problem for them?
I don't want to go too far in the direction of being willing to break things in the back-branches, for obvious reasons. But in a case like this, we definitely have a bug that is affecting users on Windows, and we can't verify whether the fallback code is correct or would ever be used by anyone. If you think that fallback code is reasonably likely to be correct and work, I'm not against including it. But if we really have no idea, then IMHO it's reasonable to ship something that we expect to cause a hard failure on such platforms if they exist (like a missing symbol). That way, if they do exist, we'll be more likely to find about it and therefore more likely to be able to deliver a complete and proper fix, vs. shipping something that might be quite wrong and praying that it isn't. -- Robert Haas EDB: http://www.enterprisedb.com
