Re: Planning incompatibilities for Postgres 10.0

From: Daniel Farina <daniel(at)fdr(dot)io>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Planning incompatibilities for Postgres 10.0
Date: 2013-05-29 06:04:16
Message-ID: CACN56+Or_+KUMcU3Y6mbpeM-CY_groU37QP1WepaMeQYWOe4uw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 27, 2013 at 9:41 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 27 May 2013 15:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>> On Mon, May 27, 2013 at 08:26:48AM -0400, Stephen Frost wrote:
>>>> That said, many discussions and ideas do get shut down, perhaps too
>>>> early, because of pg_upgrade considerations. If we had a plan to have
>>>> an incompatible release in the future, those ideas and discussions might
>>>> be able to progress to a point where we determine it's worth it to take
>>>> the pain of a non-pg_upgrade-supported release. That's a bit of a
>>>> stretch, in my view, but I suppose it's possible. Even so though, I
>>>> would suggest that we put together a wiki page to list out those items
>>>> and encourage people to add to such a list; perhaps having an item on
>>>> that list would make discussion about it progress beyond "it breaks
>>>> pg_upgrade".
>>
>>> Yes, we should be collecting things we want to do for a pg_upgrade break
>>> so we can see the list all in one place.
>>
>> Precisely. We've said right along that we reserve the right to have a
>> non-upgradable disk format change whenever sufficiently many reasons
>> accumulate to do that.

Here's one that's come up a few times: being able to tweak the
out-of-line storage strategy, e.g. change the compression format used.
I think some folks were lamenting the lack of a convenient byte in
the right place for that one.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2013-05-29 07:30:43 Re: pg_dump with postgis extension dumps rules separately
Previous Message Joshua D. Drake 2013-05-29 04:08:03 Re: [GENERAL] pg_upgrade -u