Re: status/timeline of pglogical?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Vik Fearing <vik(at)2ndquadrant(dot)fr>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, Josh berkus <josh(at)agliodbs(dot)com>, pgsql-advocacy <pgsql-advocacy(at)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>
Subject: Re: status/timeline of pglogical?
Date: 2016-05-12 14:57:30
Message-ID: 20160512145729.GB2632@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy

On Thu, May 12, 2016 at 10:37:28AM -0400, Robert Haas wrote:
> 3. I think we need to replace pg_upgrade with a real in-place upgrade
> scheme so that you just fire up the new version of the server on your
> old data directory, and it rejiggers things in place without needing
> to create a new cluster and migrate stuff over to it. I think that
> actually making this work is a huge engineering effort, and I have no
> plans to undertake it in the near term, but I think it has to be done.
> pg_upgrade isn't reliable enough, and using pglogical means you need a
> second machine. Maybe everybody should run with a standby, but not
> everyone does.

I don't see why you can't have the pg_logical slave be on the same
server as the master for an upgrade. It will double the write volume
while it is active, but assuming it is setup only to perform a major
version upgrade, it should be fine.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Bruce Momjian 2016-05-12 15:03:03 Re: status/timeline of pglogical?
Previous Message Greg Sabino Mullane 2016-05-12 14:53:38 New versioning scheme