Re: Planning incompatibilities for Postgres 10.0 - Mailing list pgsql-hackers

On 25 May 2013 21:44, Bruce Momjian <bruce@momjian.us> wrote:
> On Sat, May 25, 2013 at 10:39:30AM +0100, Simon Riggs 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
>
> Assuming online upgrade is going to require logical replication, you are
> also assuming 2x storage as you need to have a second cluster to perform
> the upgrade.

The people that want online upgrade already have 1+ other systems to
do this with.


> pg_upgrade would still be needed to upgrade a cluster
> in-place.
> This sounds like, "I created a new tool which does some of what the old
> tool does.  Let's break the old tool to allow some unspecified changes I
> might want to make."

I haven't argued against pg_upgrade in general, nor said anything
about breaking it. I proposed that we don't support a pg_upgrade path
between two near-future releases, as a way of introducing
incompatibilities. After that, we would continue to use pg_upgrade for
later releases.

Logical replication is being developed, which gives us a complete code
path for doing what we'd need to do. The most important thing is we
wouldn't need to develop any other code that exists just for upgrade.

Writing special code just for pg_upgrade will take a lot of work.
Running that code would mean pg_upgrade would touch the actual
database, which would be down for a long time while it runs. And if it
hits a bug during or after, you're hosed. So you'd need to take a full
backup before you started the process, probably storing it on disk
somewhere and so you would need x2 disk space with this route also.
Specialised code is less well tested, which means bugs are more likely
to occur and tends to perform more poorly. Not only that, but the
first person to want an incompatibility gets to write all the code
needed and take responsibility for the bugs. I can't comment for
others, but I can say I would not personally choose that route - it
looks both expensive and risky.


> I consider this thread to be not thought-through, obviously.

My proposal has had lots of serious consideration, but that is not the
topic of this thread.

The title of the thread is a general one, with a clear objective.

I'm looking for a way forwards that allows us to introduce the changes
that many have proposed and which regrettably result in
incompatibilities. If we have no plan I think its likely it will never
happen and it is currently blocking useful change.

Please explain what you consider to be a better plan, so we can judge
all proposals together.

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