Re: pg_upgrade supported versions policy

Поиск
Список
Период
Сортировка
От David Fetter
Тема Re: pg_upgrade supported versions policy
Дата
Msg-id 20181123211011.GL958@fetter.org
обсуждение исходный текст
Ответ на pg_upgrade supported versions policy  (Andres Freund <andres@anarazel.de>)
Ответы Re: pg_upgrade supported versions policy  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
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


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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Shared Memory: How to use SYSV rather than MMAP ?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: tab-completion debug print