From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_dump versus ancient server versions
Date: Thu, 09 Dec 2021 12:50:40 -0500
Message-ID: <3794414.1639072240@sss.pgh.pa.us> (raw)
In-Reply-To: <2978297.1638751274@sss.pgh.pa.us>
References: <CA+TgmoboH6=SgWHPddv_8ie91Qf2ECKSvg-72aYajKb2gyLYQg@mail.gmail.com>
<202110222351.3f42l5fgo3lw@alvherre.pgsql>
<CA+TgmobB8cj30z6dzEf5xNTxzGRNGmkJsCr3nv_Hneo0o5kozg@mail.gmail.com>
<3783090.1635111977@sss.pgh.pa.us>
<CA+TgmobQxeGVtgxQz_OxdgCO4r=Tb2SaCh9FJ8Dxjaq9DxHH_g@mail.gmail.com>
<3883429.1635171820@sss.pgh.pa.us>
<20211025170657.ekufa7urdcyzpgdm@alap3.anarazel.de>
<c51ede27-3b6d-1d27-9d1a-227526858db2@dunslane.net>
<22018.1635202338@sss.pgh.pa.us>
<d0316012-ece7-7b7e-2d36-9c38cb77cb3b@enterprisedb.com>
<20211202221607.xovsdnoh5tpbnhbs@alap3.anarazel.de>
<196b40be-c571-e77f-3335-920f8a00047f@enterprisedb.com>
<2316211.1638556231@sss.pgh.pa.us>
<CA+Tgmob0V3dJ57vKL1iouk1oLMFn-60eAUQ+ab6=1BDG7ZC8iw@mail.gmail.com>
<2978297.1638751274@sss.pgh.pa.us>
[ 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com, andrew@dunslane.net, andres@anarazel.de, robertmhaas@gmail.com, bruce@momjian.us, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
Subject: Re: pg_dump versus ancient server versions
In-Reply-To: <3794414.1639072240@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox