Re: A Modest Upgrade Proposal

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

In response to

Browse pgsql-hackers by date

  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