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:
== 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.
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 …
|
