Horton

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

Bruce Momjian <bruce@momjian.us>

View thread View on postgr.es
From: Bruce Momjian <bruce@momjian.us>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, 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-21T16:15:02Z
Lists: pgsql-hackers 
On Tue, Jun 21, 2016 at 08:56:09PM +0800, Craig Ringer wrote:
> Also, if you run *with* --link, IIRC there's no guarantee that the old version
> will be happy to see any new infomask bits etc introduced by the new Pg. I

Well, we only write system tables in pg_upgrade in the new cluster, and
those are not hard linked.  As far as I know, we never write to anything
we hard link from the old cluster.

> think there will also be issues with oid to relfilenode mappings in pg_class if
> the new cluster did any VACUUM FULLs or anything. It seems likely to be a bit

pg_upgrade turns off all vacuums.

> risky to fall back on the old cluster once you've upgraded with --link . TBH it
> never even occurred to me that it'd be possible at all until you mentioned.

Well, with --link, you can't start the old cluster, and that is
documented, and pg_control is renamed to prevent accidental start.  I
think it is possible to start the old cluster before the new cluster is
started.

> I always thought of pg_upgrade as a one-way no-going-back process either way,
> really. Either due to a fork in history (without --link) or due to possibly
> incompatible datadir changes (with --link).

Yes.

-- 
  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 +