Re: pg_dump versus ancient server versions

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