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.
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 |