Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
От | Bruce Momjian |
---|---|
Тема | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 |
Дата | |
Msg-id | 20160621161502.GH24184@momjian.us обсуждение исходный текст |
Ответ на | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 (Craig Ringer <craig@2ndquadrant.com>) |
Список | 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 +
В списке pgsql-hackers по дате отправления: