Release Note changes
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.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
På mandag 04. september 2017 kl. 10:49:40, skrev Simon Riggs <
simon@2ndquadrant.com <mailto:simon@2ndquadrant.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
On Mon, Sep 4, 2017 at 4:49 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
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 ...
Fair point.
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."
It's not really true that the only alternatives to pglogical are
proprietary. Really, one could use any logical replication solution,
and there have been multiple open source alternatives for a decade.
Our docs mention pglogical already, so don't see an issue with
mentioning it here.
The existing reference is alongside a bunch of other third-party
tools. Mentioning it at the very top of our release notes would give
it a pride of place with which I'm not too comfortable.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Sep 4, 2017 at 1:11 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Sep 4, 2017 at 4:49 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
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 ...
Fair point.
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."It's not really true that the only alternatives to pglogical are
proprietary. Really, one could use any logical replication solution,
and there have been multiple open source alternatives for a decade.Our docs mention pglogical already, so don't see an issue with
mentioning it here.The existing reference is alongside a bunch of other third-party
tools. Mentioning it at the very top of our release notes would give
it a pride of place with which I'm not too comfortable.
I agree that singling it out there is probably not the best idea. But a
sentence/paragraph saying that there are third party replication solutions
that can solve the problem, along with linking to the page with the list,
perhaps?
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
On Mon, Sep 4, 2017 at 7:14 AM, Magnus Hagander <magnus@hagander.net> wrote:
I agree that singling it out there is probably not the best idea. But a
sentence/paragraph saying that there are third party replication solutions
that can solve the problem, along with linking to the page with the list,
perhaps?
Yeah, that seems fine.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 4 September 2017 at 12:39, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Sep 4, 2017 at 7:14 AM, Magnus Hagander <magnus@hagander.net> wrote:
I agree that singling it out there is probably not the best idea. But a
sentence/paragraph saying that there are third party replication solutions
that can solve the problem, along with linking to the page with the list,
perhaps?Yeah, that seems fine.
A link to our docs page that covers those would be fine.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 4 September 2017 at 10:34, Andreas Joseph Krogh <andreas@visena.com> wrote:
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.
Sounds like we could change that, or at least add a WARNING that there are LOs.
Patches welcome.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 4 September 2017 at 12:11, Robert Haas <robertmhaas@gmail.com> wrote:
It's not really true that the only alternatives to pglogical are
proprietary. Really, one could use any logical replication solution,
and there have been multiple open source alternatives for a decade.
True, but it is by far the best solution out of the many choices.
Which is why next year when upgrading from PG10 -> PG11 we will
mention it and that point not mention the other older solutions, which
were once our best.
Our docs mention pglogical already, so don't see an issue with
mentioning it here.The existing reference is alongside a bunch of other third-party
tools. Mentioning it at the very top of our release notes would give
it a pride of place with which I'm not too comfortable.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
Which is why next year when upgrading from PG10 -> PG11 we will
mention it and that point not mention the other older solutions, which
were once our best.
This is boilerplate text that we tend to copy-and-paste without thinking
about it; if it's designed in a way that requires it to change more than
about once per decade, that's going to be a problem. (The existing text
has been there verbatim since 9.0, looks like.)
I'm okay with a passing reference to some list of replication tools
elsewhere in the docs, but not with much more than that.
It's also worth pointing out that the existing wording is meant to
explain how to achieve upgrade-in-place. Logical replication to a
new server seems like a fundamentally different thing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers