Re: pg_dump versus ancient server versions

[ mostly for the archives' sake ]

I wrote:
> 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:

> * 9.1 fails with "conflicting types for 'base_yylex'", much as
> I saw on macOS except it's a hard error on this compiler.

I poked a little harder at what might be needed to get 9.1 compiled
on modern platforms. It looks like the base_yylex issue is down
to newer versions of flex doing things differently. We fixed
that in the v10 era via 72b1e3a21 (Build backend/parser/scan.l and
interfaces/ecpg/preproc/pgc.l standalone) and 92fb64983 (Use "%option
prefix" to set API names in ecpg's lexer), which were later back-patched
as far down as 9.2. It might not be out of the question to back-patch
those further, but the 9.2 patches don't apply cleanly to 9.1, so some
effort would be needed.

Worrisomely, I also noted warnings like

parse_coerce.c:791:67: warning: array subscript 1 is above array bounds of 'Oid[1]' {aka 'unsigned int[1]'} [-Warray-bounds]
791 | Assert(nargs < 2 || procstruct->proargtypes.values[1] == INT4OID);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~

which remind me that 9.1 lacks 8137f2c32 (Hide most variable-length fields
from Form_pg_* structs). We did stick -fno-aggressive-loop-optimizations
into 9.1 and older branches back in 2015, but I don't have a lot of
confidence that that'd be sufficient to prevent misoptimizations in
current-vintage compilers. Back-patching 8137f2c32 and all the follow-on
work is very clearly not something to consider, so dialing down the -O
level might be necessary if you were interested in making this go.

In short then, there is a really large gap between 9.1 and 9.2 in terms
of how hard they are to build on current toolchains. It's kind of
fortunate that Peter proposed 9.2 rather than some earlier cutoff.
In any case, I've completely lost interest in trying to move the
keep-it-buildable cutoff to any earlier than 9.2; it doesn't look
like the effort-to-benefit ratio would be attractive at all.

regards, tom lane