Horton

Re: pg_dump versus ancient server versions

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>, Bruce Momjian <bruce@momjian.us>, Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-12-02T22:16:07Z
Lists: pgsql-hackers 
Hi,

On 2021-12-02 11:01:47 +0100, Peter Eisentraut wrote:
> - The policy for other client-side tools (list at [0]) is less clear
>   and arguably less important.  I suggest we focus on pg_dump and psql
>   first, and then we can decide for the rest whether they want to
>   match a longer window, a shorter window, or a different policy
>   altogether (e.g., ecpg).

I think we should at least include pg_upgrade in this as well, it's pretty
closely tied to at least pg_dump.


> * pg_dump and psql will maintain compatibility with servers at least
>   ten major releases back.

Personally I think that's too long... It boils down keeping branches buildable
for ~15 years after they've been released. That strikes me as pretty far into
diminishing-returns, and steeply increasing costs, territory.

I realize it's more complicated for users, but a policy based on supporting a
certain number of out-of-support branches calculated from the newest major
version is more realistic. I'd personally go for something like newest-major -
7 (i.e. 2 extra releases), but I realize that others think it's worthwhile to
support a few more.  I think there's a considerable advantage of having one
cutoff date across all branches.

That's not to say we'd remove support for older versions from back
branches. Just that we don't ever consider them supported (or test them) once
below the cutoff.


> I use the count of major releases here instead of some number of
> years, as was previously discussed, for two reasons.  First, it makes
> computing the cutoff easier, because you are not bothered by whether
> some old release was released a few weeks before or after the
> equivalent date in the current year for the new release.  Second,
> there is no ambiguity about what happens during the lifetime of a
> major release: If major release $NEW supports major release $OLD at
> the time of $NEW's release, then that stays the same for the whole
> life of $NEW; we don't start dropping support for $OLD in $NEW.5
> because a year has passed.

Makes sense.


> * We keep old major release branches buildable as long as a new major
>   release that has support for that old release is under support.

> Buildable for this purpose means just enough that you can use it to
> test pg_dump and psql.  This probably includes being able to run make
> installcheck and use pg_dump and psql against the regression database.

I think we should explicitly limit the number of platforms we care about for
this purpose. I don't think we should even try to keep 8.2 compile on AIX or
whatnot.

Greetings,

Andres Freund

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