Re: pg_upgrade supported versions policy - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: pg_upgrade supported versions policy
Date
Msg-id a829b055-5159-4be0-80a5-946f3ecfa989@2ndQuadrant.com
Whole thread Raw
In response to Re: pg_upgrade supported versions policy  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: 64-bit hash function for hstore and citext data type
Next
From: Andres Freund
Date:
Subject: Re: [RFC] Removing "magic" oids