I ran a new set of experiments concerning building back branches on modern platforms, this time trying Fedora 35 (gcc 11.2.1) on x86_64. I widened the scope of the testing a bit by adding "--enable-nls --with-perl" and running check-world not just the core tests. Salient results:
* Everything back to 9.2 passes the test, although with more and more compile warnings the further back you go. * 9.1 fails with "conflicting types for 'base_yylex'", much as I saw on macOS except it's a hard error on this compiler. * Parallel check-world is pretty unreliable before v10 (I knew this already, actually). But without parallelism, it's fine. Based on these results, I think maybe we should raise our ambitions a bit compared to Peter's original proposal. Specifically, I wonder if it wouldn't be wise to try to silence compile warnings in these branches. The argument for this is basically that if we don't, then every time someone builds one of these branches, they have to tediously go through the warnings and verify that they're not important. It won't take long for the accumulated time-wastage from that to exceed the cost of back-patching whatever we did to silence the warning in later branches. Now, I'm still not interested in trying to silence maybe-uninitialized warnings pre-9.3, mainly because of the ereport-ERROR-doesnt-return issue. (I saw far fewer of those under gcc than clang, but not zero.) We could ignore those figuring that 9.2 will be out of scope in a year anyway, or else teach 9.2's configure to select -Wno-maybe-uninitialized where possible. Likewise, getting check-world to parallelize successfully pre-v10 seems like a bridge too far. But I would, for example, be in favor of back-patching eb9812f27 (Make pg_upgrade's test.sh less chatty). It's just annoying to run check-world and get that output now. regards, tom lane