Re: Planning incompatibilities for Postgres 10.0

From: Bruce Momjian <bruce(at)momjian(dot)us>
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-25 20:44:35
Message-ID: 20130525204435.GA32064@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. 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 consider this thread to be not thought-through,
obviously.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2013-05-25 20:47:05 Re: pg_export_snapshot on standby side
Previous Message Jon Nelson 2013-05-25 18:55:09 Re: fallocate / posix_fallocate for new WAL file creation (etc...)