Re: pg_upgrade supported versions policy

Greetings,

* Andres Freund (andres(at)anarazel(dot)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