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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to