On 25 May 2013 21:44, Bruce Momjian 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 people that want online upgrade already have 1+ other systems to
do this with.
pg_upgrade would still be needed to upgrade a cluster
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
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.