Horton

Re: pg_dump versus ancient server versions

Andrew Dunstan <andrew@dunslane.net>

View thread View on postgr.es
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-10-26T17:59:34Z
Lists: pgsql-hackers 
On 10/25/21 13:09, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2021-10-22 19:30:25 -0400, Tom Lane wrote:
>>> Yeah.  I checked into when it was that we dropped pre-8.0 support
>>> from pg_dump, and the answer is just about five years ago (64f3524e2).
>>> So moving the bar forward by five releases isn't at all out of line.
>>> 8.4 would be eight years past EOL by the time v15 comes out.
>> I'd really like us to adopt a "default" policy on this. I think it's a waste
>> to spend time every few years arguing what exact versions to drop. I'd much
>> rather say that, unless there are concrete reasons to deviate from that, we
>> provide pg_dump compatibility for 5+3 releases, pg_upgrade for 5+1, and psql
>> for 5 releases or something like that.
> I agree with considering something like that to be the minimum support
> policy, but the actual changes need a bit more care.  For example, when
> we last did this, the technical need was just to drop pre-7.4 versions,
> but we chose to make the cutoff 8.0 on the grounds that that was more
> understandable to users [1].  In the same way, I'm thinking of moving the
> cutoff to 9.0 now, although 8.4 would be sufficient from a technical
> standpoint.
>
> OTOH, in the new world of one-part major versions, it's less clear that
> there will be obvious division points for future cutoff changes.  Maybe
> versions-divisible-by-five would work?  Or versions divisible by ten,
> but experience so far suggests that we'll want to move the cutoff more
> often than once every ten years.
>
> 	


pg_upgrade claims to be able to operate on 8.4, which might be all the
better for some regular testing (which this could enable), so that seems
to me more like where the cutoff should be at least for this round.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

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