Re: pg_upgrade supported versions policy

From: Andres Freund <andres(at)anarazel(dot)de>
To: David Fetter <david(at)fetter(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_upgrade supported versions policy
Date: 2018-11-23 21:46:26
Message-ID: 91C51682-61EF-45A0-8452-65E80A9CDFFA@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On November 23, 2018 1:10:11 PM PST, David Fetter <david(at)fetter(dot)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 does not guarantee the page has been written in that version.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-11-23 23:20:40 Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-ed data
Previous Message Tom Lane 2018-11-23 21:32:31 Re: tab-completion debug print