Greetings, * Andres Freund (and...@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
signature.asc
Description: PGP signature