Re: Planning incompatibilities for Postgres 10.0

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.

I'm happy with that.

I was also thinking about collecting changes not related just to disk
format, if any exist.

> The way to go about that is to collect projects
> that need to be kept on hold for such a release --- not to say we're
> going to have such a release and then look for reasons.

Agreed.

I was trying to establish a realistic timeline for such events, so
that the planning was able to be taken seriously. Yes, it wass a "work
backwards" or "what if" type of planning. But now we have a rough plan
of how it might look, collecting ideas can begin.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services