Re: pg_upgrade supported versions policy

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: pg_upgrade supported versions policy
Дата
Msg-id 91C51682-61EF-45A0-8452-65E80A9CDFFA@anarazel.de
обсуждение исходный текст
Ответ на Re: pg_upgrade supported versions policy  (David Fetter <david@fetter.org>)
Список pgsql-hackers

On November 23, 2018 1:10:11 PM PST, David Fetter <david@fetter.org> wrote:
>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?

I don't think this has anything to do with the storage format. See also my answer to Stephen. Where we upgrade from
doesnot guarantee the page has been written in that version. 

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: tab-completion debug print
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-eddata