From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Planning incompatibilities for Postgres 10.0 |
Date: | 2013-05-28 15:03:56 |
Message-ID: | CAHyXU0zvTkEfjsZUJ-dyfmxNnLEBM-HWY-JrtsHmV3n0ZzHmJg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 25, 2013 at 11:27 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Sat, May 25, 2013 at 4:39 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> There are a number of changes we'd probably like to make to the way
>> things work in Postgres. This thread is not about discussing what
>> those are, just to say that requirements exist and have been discussed
>> in various threads over time.
>>
>> The constraint on such changes is that we've decided that we must have
>> an upgrade path from release to release.
>>
>> So I'd like to make a formal suggestion of a plan for how we cope with this:
>>
>> 1. Implement online upgrade in 9.4 via the various facilities we have
>> in-progress. That looks completely possible.
>>
>> 2. Name the next release after that 10.0 (would have been 9.5). We
>> declare now that
>> a) 10.0 will support on-line upgrade from 9.4 (only)
>> b) various major incompatibilities will be introduced in 10.0 - the
>> change in release number will indicate to everybody that is the case
>> c) agree that there will be no pg_upgrade patch from 9.4 to 10.0, so
>> that we will not be constrained by that
>>
>> This plan doesn't presume any particular change. Each change would
>> need to be discussed on a separate thread, with a separate case for
>> each. All I'm suggesting is that we have a coherent plan for the
>> timing of such changes, so we can bundle them together into one
>> release.
>>
>> By doing this now we give ourselves lots of time to plan changes that
>> will see us good for another decade. If we don't do this, then we
>> simply risk losing the iniative by continuing to support legacy
>> formats and approaches.
>
> Huh. I don't think that bumping the version number to 10.0 vs 9.5 is
> justification to introduce breaking changes. In fact, I would rather
> see 10.0 be the version where we formally stop doing that. I
> understand that some stuff needs to be improved but it often doesn't
> seem to be worth the cost in the long run.
Please disregard this comment -- I didn't realize the topic was
regarding on disk format -- I mistakenly though it was opening the
door for user level feature changes.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Jon Nelson | 2013-05-28 15:12:05 | Re: fallocate / posix_fallocate for new WAL file creation (etc...) |
Previous Message | Benedikt Grundmann | 2013-05-28 14:53:59 | Re: streaming replication, "frozen snapshot backup on it" and missing relfile (postgres 9.2.3 on xfs + LVM) |