Horton

Re: pg_dump versus ancient server versions

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Bruce Momjian <bruce@momjian.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-12-12T06:24:24Z
Lists: pgsql-hackers 
Andrew Dunstan <andrew@dunslane.net> writes:
> 9.2 is how far back crake goes in testing pg_ugrade from old versions,
> so that could well be a convenient stopping point. For older versions
> there is still the possibility of building on older toolchains and
> running on modern ones. Yes it's more cumbersome, but it does mean we
> can test an awful long way back.

Right.  I think the point of the current discussion is to ensure that,
if we expect new patches for pg_dump or psql to work against version-N
servers, that it's not too unpleasant for patch submitters to build
and test against version N.  There's a different discussion to be had
about what we do if we receive a bug report about compatibility with
some more-ancient-than-that version.  But that is, I hope, a far less
common scenario; so it's okay if it requires extra effort, and/or use
of setups that not everyone has handy.

Anyway, it seems like there's some consensus that 9.2 is a good
stopping place for today.  I'll push forward with
(1) back-patching as necessary to make 9.2 and up build cleanly
on the platforms I have handy;
(2) ripping out pg_dump's support for pre-9.2 servers;
(3) ripping out psql's support for pre-9.2 servers.

In a preliminary look, it did not seem that (3) would save very
much code, but it seems like we ought to do it if we're being
consistent.

A point we've not discussed is whether to drop any bits of libpq
that are only needed for such old servers.  I feel a bit more
uncomfortable about that, mainly because I'm pretty sure that
only a few lines of code would be involved, and it seems to have
more of an air of burning-the-bridges finality about it than (say)
dropping psql/describe.c support.  On the other hand, the point
about what's required to test future patches still applies.

			regards, tom lane

Commits

  1. Remove psql support for server versions preceding 9.2.

  2. Clean up some more freshly-dead code in pg_dump and pg_upgrade.

  3. Remove pg_dump's --no-synchronized-snapshots switch.

  4. Remove pg_upgrade support for upgrading from pre-9.2 servers.

  5. Remove pg_dump/pg_dumpall support for dumping from pre-9.2 servers.

  6. Suppress -Warray-bounds warning in 9.2's xlog.c.

  7. Suppress -Wformat-overflow warnings in 9.2's xml.c.

  8. Disable -Wsometimes-uninitialized warnings in the 9.2 branch.

  9. Fix function return type confusion

  10. Fix compiler warning

  11. Silence another gcc 11 warning.

  12. Suppress uninitialized-variable warning in guc.c.

  13. Suppress -Warray-parameter warnings in pgcrypto/sha2.c.

  14. Reformat imath.c macro to remove -Wmisleading-indentation warnings.

  15. Clean up compilation warnings coming from PL/Perl with clang-12~

  16. Make ecpg's rjulmdy() and rmdyjul() agree with their declarations.

  17. Use -Wno-format-truncation and -Wno-stringop-truncation, if available.

  18. Make pg_upgrade's test.sh less chatty.

  19. Add checks for valid multibyte character length in UtfToLocal, LocalToUtf.

  20. Use return instead of exit() in configure

  21. Add support for Visual Studio 2019 in build scripts