Re: pg_upgrade supported versions policy

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