Обсуждение: pg_upgrade supported versions policy
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. Greetings, Andres Freund
Greetings, * Andres Freund (andres@anarazel.de) wrote: > 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 agree with having policies but I'm not sure that I agree with cutting it quite that far back. We only just recently agree to drop support for pg_dump from ancient versions and that seems like a pretty big deal to me. On the other hand, pg_upgrade doesn't go back that far to begin with, so perhaps the 9.0 cutoff wouldn't be that bad. The going-forward policy is the more difficult one to work out. I'll also point out that I suspect the policy defined here will end up having impacts elsewhere- how far back do we support btree version X? Well, we need to support it as far back as we support pg_upgrade, so let's be thinking about this in that light. > 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. This is saying that we'll support pg_upgrade for 5 prior versions, right? Version 15 will work with version 10, but not older, and v16 won't work with v10 but will with v11? Compared to today, where we are closer to 10 years of support. Thinking about it, I have to admit that I feel much more strongly about maintaining pg_dump support than pg_upgrade, but that's where things start to go sideways- a lot of what pg_upgrade does is actually supported through pg_dump. > 2) Same, but +2 releases or such. That could possibly work.. > 3) Support until it gets too uncomfortable. No, please not this. > 4) Support all versions remotely feasible (i.e. don't drop versions that > still can be compiled) Also, no, not this. > I personally think 1 is preferrable and 2 is acceptable. Given how closely pg_upgrade and pg_dump are intertwined, I'd rather we keep the back-branch support the same for both. At the same time, I don't like having a lot of support in the backend for older versions of on-disk data. I suppose I'm squarely on the fence, but perhaps some of this is helpful to others thinking about this. Thanks! Stephen
Вложения
Hi, On 2018-11-21 19:25:45 -0500, Stephen Frost wrote: > * Andres Freund (andres@anarazel.de) wrote: > > 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 agree with having policies but I'm not sure that I agree with cutting > it quite that far back. We only just recently agree to drop support for > pg_dump from ancient versions and that seems like a pretty big deal to > me. I don't really think the pg_dump part is actually a big deal - and I think pg_dump support for ancient versions is much more crucial than pg_upgrade support. > I'll also point out that I suspect the policy defined here will end up > having impacts elsewhere- how far back do we support btree version X? I don't think that's true - the on-disk data can be much older, even when upgrading from a newer cluster. As pg_upgrades don't touch the majority of the on-disk data, upgrading from a certain cluster version doesn't guarantee anything about the data. Fixing that by enforcing that there needs to be a vacuum (or other full table process) on old relations is a separate discussion imo (and obviously is only possible from 12+). > > 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. > > This is saying that we'll support pg_upgrade for 5 prior versions, > right? Version 15 will work with version 10, but not older, and v16 > won't work with v10 but will with v11? Yes. > > I personally think 1 is preferrable and 2 is acceptable. > > Given how closely pg_upgrade and pg_dump are intertwined, I'd rather we > keep the back-branch support the same for both. I don't buy this. The majority of the cross-version support in pg_dump doesn't have much to do with binary upgrade mode. And the version specific logic in pg_upgrade itself is independent. Which intertwinedness are you seeing? > At the same time, I don't like having a lot of support in the backend > for older versions of on-disk data. As I said, i don't see this being related. Greetings, Andres Freund
On Thu, Nov 22, 2018 at 12:48 AM Andres Freund <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.
3 and 4 both causes a lot of work on the dev side, but also makes it a lot less predictable for the end users. I'm willing to be many of them prefer a defined policy even if it's a bit shorter than the limits we have now, to a "sorry we dont know" kind of policy. Thus, -1 for both 3 and 4.
On 22/11/2018 00:47, Andres Freund wrote: > 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 would prefer #3. That's basically how we handle pg_dump, psql, etc. normally. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Nov 22, 2018 at 7:57 AM Magnus Hagander <magnus@hagander.net> wrote: > > On Thu, Nov 22, 2018 at 12:48 AM Andres Freund <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 thatfar too many don't realize they should upgrade on time, but at least a fair number of them notice within one cycle fromit going EOL -- perhaps just by reading the announcement saying "hey version x is now EOL". And supporting +1 or +2 versionsmakes it possible for them to go directly to latest. +1 Just looking at the Postgres versions we are supporting inside our company, we have many/most products leveraging 9.4 currently and they are just starting to think about how to upgrade. My assumption is many teams will get it together enough to upgrade by the time 9.4 is no longer supported, however, many will not and getting them to the latest stable version in one jump would be really nice. -- Rob > > 3 and 4 both causes a lot of work on the dev side, but also makes it a lot less predictable for the end users. I'm willingto be many of them prefer a defined policy even if it's a bit shorter than the limits we have now, to a "sorry wedont know" kind of policy. Thus, -1 for both 3 and 4. > > -- > Magnus Hagander > Me: https://www.hagander.net/ > Work: https://www.redpill-linpro.com/
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
On Wed, Nov 21, 2018 at 03:47:22PM -0800, Andres Freund 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) The way pg_upgrade works right now, 1), 2), and 4) basically make it impossible to change our storage format in any non-trivial way, and 3) is a "trivial case" in the sense that the first such non-trivial storage format change ends pg_upgrade support. Are we really that attached to how we store things? Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On November 23, 2018 1:10:11 PM PST, David Fetter <david@fetter.org> wrote: >On Wed, Nov 21, 2018 at 03:47:22PM -0800, Andres Freund 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) > >The way pg_upgrade works right now, 1), 2), and 4) basically make it >impossible to change our storage format in any non-trivial way, and 3) >is a "trivial case" in the sense that the first such non-trivial >storage format change ends pg_upgrade support. > >Are we really that attached to how we store things? I don't think this has anything to do with the storage format. See also my answer to Stephen. Where we upgrade from doesnot guarantee the page has been written in that version. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.