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 <br...@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 + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
