Re: pg_upgrade supported versions policy

Hi,

On 2018-11-21 19:25:45 -0500, Stephen Frost wrote:
> * 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.

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