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: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2021-10-22T23:48:13Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> Another thing to think about in that regard: how likely is that
> PostgreSQL 7.4 and PostgreSQL 15 both compile and run on the same
> operating system? I suspect the answer is "not very." I seem to recall
> Greg Stark trying to compile really old versions of PostgreSQL for a
> conference talk some years ago, and he got back to a point where it
> just became impossible to make work on modern toolchains even with a
> decent amount of hackery.

Right.  The toolchains keep moving, even if the official language
definition doesn't.  For grins, I just checked out REL8_4_STABLE
on my M1 Mac, and found that it only gets this far:

checking test program... ok
checking whether long int is 64 bits... no
checking whether long long int is 64 bits... no
configure: error: Cannot find a working 64-bit integer type.

which turns out to be down to a configure-script issue we fixed
some years ago, ie using exit() without a prototype:

conftest.c:158:3: error: implicitly declaring library function 'exit' with type\
 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaratio\
n]
  exit(! does_int64_work());
  ^

I notice that the configure script is also selecting some warning
switches that this compiler doesn't much like, plus it doesn't
believe 2.6.x flex is usable.  So that's *at least* three things
that'd have to be hacked even to get to a successful configure run.

Individually such issues are (usually) not very painful, but when
you have to recreate all of them at once it's a daunting project.

So if I had to rebuild 8.4 from scratch right now, I would not be
a happy camper.  That seems like a good argument for not deeming
it to be something we still have to support.

			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