From: | Andreas Joseph Krogh <andreas(at)visena(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Release Note changes |
Date: | 2017-09-04 09:34:28 |
Message-ID: | VisenaEmail.10.2d281e3a3f61da8f.15e4c395779@tc7-visena |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
På mandag 04. september 2017 kl. 10:49:40, skrev Simon Riggs <
simon(at)2ndquadrant(dot)com <mailto:simon(at)2ndquadrant(dot)com>>:
Migration to Version 10
"A dump/restore using pg_dumpall, or use of pg_upgrade, is required
for those wishing to migrate data from any previous release."
This isn't true and is seriously misleading since pglogical and other
proprietary tools exist that were designed specifically to allow this.
Suggested additional wording would be...
"If upgrading from a 9.4 server or later, external utilities using
logical decoding, such as pglogical or proprietary alternatives, can
also provide an alternate route, often with lower downtime."
Our docs mention pglogical already, so don't see an issue with
mentioning it here.
I'd like at big red warning "Logical decoding doesn't support Large Objects"
in that case;
"If upgrading from a 9.4 server or later, and you don't use Large Objects,
external utilities using logical decoding, such as pglogical or
proprietary alternatives, can also provide an alternate route,
often with lower downtime."
pg_upgrade or pg_dump is really the only option for us using LOs.
-- Andreas Joseph Krogh
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-09-04 09:46:28 | Re: Parallel worker error |
Previous Message | Sokolov Yura | 2017-09-04 09:29:06 | Re: Proposal: pg_rewind to skip config files |