Re: pg_upgrade supported versions policy

Поиск
Список
Период
Сортировка
От Robert Eckhardt
Тема Re: pg_upgrade supported versions policy
Дата
Msg-id CAAtBm9V-RcwQWHRxKzuGgN1Q=NqFOKEGvA65FoXSuG7HtkFmKg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade supported versions policy  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
On Thu, Nov 22, 2018 at 7:57 AM Magnus Hagander <magnus@hagander.net> wrote:
>
> On Thu, Nov 22, 2018 at 12:48 AM Andres Freund <andres@anarazel.de> 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)
>>
>> I personally think 1 is preferrable and 2 is acceptable.
>
>
> As a developer, I'd like 1. As someone who repeatedly runs into customer cases, I'd say 2. The reason for that is
thatfar too many don't realize they should upgrade on time, but at least a fair number of them notice within one cycle
fromit going EOL -- perhaps just by reading the announcement saying "hey version x is now EOL". And supporting +1 or +2
versionsmakes it possible for them to go directly to latest. 

+1 Just looking at the Postgres versions we are supporting inside our
company, we have many/most products leveraging 9.4 currently and they
are just starting to think about how to upgrade. My assumption is many
teams will get it together enough to upgrade by the time 9.4 is no
longer supported, however, many will not and getting them to the
latest stable version in one jump would be really nice.

-- Rob
>
> 3 and 4 both causes a lot of work on the dev side, but also makes it a lot less predictable for the end users. I'm
willingto be many of them prefer a defined policy even if it's a bit shorter than the limits we have now, to a "sorry
wedont know" kind of policy. Thus, -1 for both 3 and 4. 
>
> --
>  Magnus Hagander
>  Me: https://www.hagander.net/
>  Work: https://www.redpill-linpro.com/


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

Предыдущее
От: Alexander Kuzmenkov
Дата:
Сообщение: Re: Implement predicate propagation for non-equivalence clauses
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: MERGE SQL statement for PG12