> On Jul 27, 2016, at 09:59, Bruce Momjian <br...@momjian.us> wrote: > > I think long-term we are looking at pg_logical for zero-downtime > upgrades and _downgrades_, and pg_upgrade for less overhead (I don't > want to make a second copy of my data) upgrades (but not downgrades). > > I think this is probably the best we are going to be able to do for a > long time.
Stupid question here, but do we provide any less then what MySQL does? I’m reading: http://dev.mysql.com/doc/refman/5.7/en/downgrading.html#downgrade-paths <http://dev.mysql.com/doc/refman/5.7/en/downgrading.html#downgrade-paths> == Unless otherwise documented, the following downgrade paths are supported: Downgrading from a release series version to an older release series version is supported using all downgrade methods <http://dev.mysql.com/doc/refman/5.7/en/downgrading.html#downgrade-methods>. For example, downgrading from 5.7.10 to 5.7.9 is supported. Skipping release series versions is also supported. For example, downgrading from 5.7.11 to 5.7.9 is supported. Downgrading one release level is supported using the logical downgrade method. For example, downgrading from 5.7 to 5.6 is supported. Downgrading more than one release level is supported using the logical downgrade method, but only if you downgrade one release level at a time. For example, you can downgrade from 5.7 to 5.6, and then to 5.5. == So, downgrade minor releases can be done by just changing the binaries … downgrading an older ‘major release’ requires a dump/reload … Unless I’m missing something, whether on PostgreSQL or MySQL, if you want to go back a major release, you would need to dump./ reload that 1TB database … -- Marc G Fournier http://www.2ndQuadrant.com <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, RemoteDBA, Training & Services
