Thread: [HACKERS] 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

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.

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

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

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

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

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

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