Re: pg_upgrade supported versions policy

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: pg_upgrade supported versions policy
Дата
Msg-id CABUevEwCXtM=i=d4VQcE8fRc-qen04eSFwZK9JaiaMnKcCTggw@mail.gmail.com
обсуждение исходный текст
Ответ на pg_upgrade supported versions policy  (Andres Freund <andres@anarazel.de>)
Ответы Re: pg_upgrade supported versions policy  (Robert Eckhardt <reckhardt@pivotal.io>)
Re: pg_upgrade supported versions policy  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Список pgsql-hackers
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 that far too many don't realize they should upgrade on time, but at least a fair number of them notice within one cycle from it going EOL -- perhaps just by reading the announcement saying "hey version x is now EOL". And supporting +1 or +2 versions makes it possible for them to go directly to latest.

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 willing to be many of them prefer a defined policy even if it's a bit shorter than the limits we have now, to a "sorry we dont know" kind of policy. Thus, -1 for both 3 and 4.
 
--

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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)