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: Jim Nasby <Jim.Nasby@BlueTreble.com>
Cc: "Joshua D. Drake" <jd@commandprompt.com>, Josh berkus <josh@agliodbs.com>, Robert Haas <robertmhaas@gmail.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-05-16T07:36:17Z
Lists: 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 +