On 11/22/18 7:57 AM, Magnus Hagander wrote:
On Thu, Nov 22, 2018 at 12:48 AM Andres Freund <and...@anarazel.de <mailto:and...@anarazel.de>> wrote:Hi, I feel like we ought to trim the support for a few old versions from pg_upgrade. In my particular case I don't really think it's reasonable to test < 9.0 versions for pg_largeobject_metadata migrations. But I think we should create a policy that's the default, leaving individual cases aside. I can see a few possible policies: 1) Support upgrading from the set of releases that were supported when the pg_upgrade target version was released. While some will argue that this is fairly short, people above it can still upgrade ~10 years worth of versions with a single intermediary upgrade. 2) Same, but +2 releases or such. 3) Support until it gets too uncomfortable. 4) Support all versions remotely feasible (i.e. don't drop versions that still can be compiled) I personally think 1 is preferrable and 2 is acceptable.As a developer, I'd like 1. As someone who repeatedly runs into customer cases, I'd say 2. The reason for that is that far too many don't realize they should upgrade on time, but at least a fair number of them notice within one cycle from it going EOL -- perhaps just by reading the announcement saying "hey version x is now EOL". And supporting +1 or +2 versions makes it possible for them to go directly to latest.
2 seems reasonable. It's perfectly possible for the buildfarm module that does tests against old version to go back as fas as we like.
cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
