Re: pg_upgrade supported versions policy

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: pg_upgrade supported versions policy
Дата
Msg-id 20181122003444.umerl7niyvle7pzu@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: pg_upgrade supported versions policy  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: pg_upgrade supported versions policy
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: ToDo: show size of partitioned table