On Wed, Jul 27, 2016 at 12:59:59PM -0400, Bruce Momjian wrote: > On Wed, Jul 27, 2016 at 12:47:24PM -0400, Bruce Momjian wrote: > > On Wed, Jul 27, 2016 at 12:33:27PM -0400, Rakesh Kumar wrote: > > > On Wed, Jul 27, 2016 at 11:45 AM, Bruce Momjian <br...@momjian.us> wrote: > > > > > > > I agree, but I am not sure how to improve it. The big complaint I have > > > > heard is that once you upgrade and open up writes on the upgraded > > > > server, you can't re-apply those writes to the old server if you need to > > > > fall back to the old server. I also don't see how to improve that > > > > either. > > > > > > doesn't and pg_logical solve this by logically replicating and allowing > > > for > > > different architecture/version between the replication nodes ? > > > > Yes. I was saying I don't know how to improve pg_upgrade to address it. > > 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.
Oh, let me give credit to Simon, who has always seen pg_logical as providing superior upgrade options where the logical replication setup isn't a problem. -- Bruce Momjian <br...@momjian.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 + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
