Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>, "Joshua D. Drake" <jd@commandprompt.com>, Josh berkus <josh@agliodbs.com>, Justin Clift <justin@postgresql.org>, Merlin Moncure <mmoncure@gmail.com>, PostgreSQL Hackers Mailing List <pgsql-hackers@postgresql.org>, Simon Riggs <simon@2ndquadrant.com>
Date: 2016-06-21T02:08:03Z
Lists: pgsql-hackers
On Fri, May 20, 2016 at 07:40:53PM -0400, Robert Haas wrote:
> On Mon, May 16, 2016 at 3:36 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > On Sun, May 15, 2016 at 03:23:52PM -0500, Jim Nasby wrote:
> >> 2) There's no ability at all to revert, other than restore a backup. That
> >> means if you pull the trigger and discover some major performance problem,
> >> you have no choice but to deal with it (you can't switch back to the old
> >> version without losing data).
> >
> > In --link mode only
> 
> No, not really.  Once you let write transactions into the new cluster,
> there's no way to get back to the old server version no matter which
> option you used.

Yes, there is, and it is documented:

        If you ran <command>pg_upgrade</command> <emphasis>without</>
        <option>--link</> or did not start the new server, the
        old cluster was not modified except that, if linking
        started, a <literal>.old</> suffix was appended to
        <filename>$PGDATA/global/pg_control</>.  To reuse the old
        cluster, possibly remove the <filename>.old</> suffix from
        <filename>$PGDATA/global/pg_control</>; you can then restart the
        old cluster.

What is confusing you?

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +