Horton

Re: pg_dump versus ancient server versions

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-12-03T16:19:47Z
Lists: pgsql-hackers 
On 02.12.21 18:30, Tom Lane wrote:
>> This assumes a yearly major release cadence.
> 
> If the point is to not have to count dates carefully, why does the cadence
> matter?

If we were to change the release cadence, then it would be appropriate 
to review this policy.

> I can get behind something roughly like this, but I wonder if it wouldn't
> be better to formulate the policy in a reactive way, i.e. when X happens
> we'll do Y.  If we don't plan to proactively remove some code every year,
> then it seems like the policy really is more like "when something breaks,
> then we'll make an attempt to keep it working if the release is less than
> ten majors back; otherwise we'll declare that release no longer
> buildable."

This sounds like it would give license to accidentally break support for 
old releases in the code and only fix them if someone complains.  That's 
not really what I would be aiming for.

> I agree with the idea of being conservative about what outside
> dependencies we will worry about for "buildable" old versions.
> (Your nearby message about Python breakage is a good example of
> why we must limit that.)  But I wonder about, say, libxml or libicu,
> or even if we can afford to drop all the non-plpgsql PLs.  An
> example of why that seems worrisome is that it's not clear we'd
> have any meaningful coverage of transforms in pg_dump with no PLs.
> I don't have any immediate proposal here, but it seems like an area
> that needs some thought and specific policy.

Yeah, I think questions like this will currently quickly lead to dead 
ends.  We are talking 5 years this, 10 years that here.  Everybody else 
(apart from RHEL) is talking at best in the range 3-5 years.  We will 
have to figure this out as we go.

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