On 11/22/18 7:57 AM, Magnus Hagander wrote:
> On Thu, Nov 22, 2018 at 12:48 AM Andres Freund <andres@anarazel.de
> <mailto:andres@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