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

On 4/29/16 10:37 AM, Joshua D. Drake wrote:
>>> 5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables
>>> without pg_upgrade or other modification).
>>
>> Technically, this is exactly what pg_upgrade does. I think what you
>> really mean is for the backend binary to be able to read the system
>> tables and WAL files of the old clusters --- something I can't see us
>> implementing anytime soon.
>>
>
> For the most part, pg_upgrade is good enough. There are exceptions and
> it does need a more thorough test suite but as a whole, it works. As
> nice as being able to install 9.6 right on top of 9.5 and have 9.6
> magically work, it is certainly not a *requirement* anymore.

My 2 issues with pg_upgrade are:

1) It's prone to bugs, because it operates at the binary level. This is
similar to how it's MUCH easier to mess up PITR than pg_dump. Perhaps
there's no way to avoid this.

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).

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.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461