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 | 20160516073617.GA4761@momjian.us обсуждение исходный текст |
Ответ на | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: Lets (not) break all the things. Was: [pgsql-advocacy]
9.6 -> 10.0
Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 |
Список | pgsql-hackers |
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 > For many users those issues just don't matter; but in my work with financial > data it's why I've never actually used it. #2 especially was good to have > (in our case, via londiste). It also made it a lot easier to find > performance issues beforehand, by switching reporting replicas over to the > new version first. > > One other consideration is cut-over time. Swapping logical master and > replica can happen nearly instantly, while pg_upgrade needs some kind of > outage window. Right. I am thinking of writing some docs about how to avoid downtime for upgrades of various types. -- 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 по дате отправления: