Bruce Momjian <bruce@xxxxxxxxxx> writes: > On Wed, Jul 27, 2016 at 10:22:27AM -0400, Scott Mead wrote: > >> That being said, it doesn't really provide a back-out plan. The beauty of >> replication is that you can halt the upgrade at any point if need be and cut >> your (hopefully small) losses. If you use -k, you are all in. Sure, you could >> setup a new standby, stop traffic, upgrade whichever node you'd like (using -k) >> and still have the other ready in the event of total catastrophe. More often >> than not, I see DBAs and sysads lead the conversation with "well, postgres >> can't replicate from one version to another, so instead.... " followed by a >> fast-glazing of management's eyes and a desire to buy a 'commercial database'. > > I agree, but I am not sure how to improve it. The big complaint I have > heard is that once you upgrade and open up writes on the upgraded > server, you can't re-apply those writes to the old server if you need to > fall back to the old server. I also don't see how to improve that either. Hmmm, is it at least theoretically possible that if a newly upgraded system were run for an interval where *no* incompatible changes to DDL etc had been done... ...that a downgrade could be performed? Er, using a not yet invented pg_downgrade:-) I reason that the same kind of voodoo that lets us do those very quick hard linked upgrades could be used to revert as well without data loss. Such a feature would be part of whatever newer version that the upgrade was done to in the first place. That is, since higher version knew enough about lower version to rejigger everything... just maybe it could do the reverse. Had the new version been run for very long with substantial data changes, then a post-analyze on the downgraded system might be necessary as well but possibly even this could be omitted in some cases. Totally nuts? Yes, perhaps :-) FWIW > Bruce Momjian <bruce@xxxxxxxxxx> 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 + -- Jerry Sievers Postgres DBA/Development Consulting e: postgres.consulting@xxxxxxxxxxx p: 312.241.7800 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
