From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A Modest Upgrade Proposal |
Date: | 2016-07-17 18:49:43 |
Message-ID: | 0b1b89f2-67b4-9271-29ac-56efcaf010f0@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/7/16 8:17 PM, Simon Riggs wrote:
> Simplicity is key, I agree. But that's just a user interface feature,
> not a comment on what's underneath the covers. pg_upgrade is not simple
> and is never likely to be so, under the covers.
Right, and what I'd prefer effort put into is making managing
replication in all forms easier. Replication has a lot of uses outside
of upgrades.
FWIW, I've actually never used pg_upgrade because I view it as high-risk
for the environments I've dealt with. There's no ability to fall back to
the old version without losing data, and because of it's binary nature
the odds of some kind of a corruption event happening are far higher
than with something like londiste. Certainly many environments don't
have those concerns though. Having options are good.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-07-17 18:50:52 | Re: A Modest Upgrade Proposal |
Previous Message | Robert Haas | 2016-07-17 18:27:24 | Re: One process per session lack of sharing |