Re: Better Upgrades - Mailing list pgsql-hackers

From David Fetter
Subject Re: Better Upgrades
Date
Msg-id 20180305125933.GL25493@fetter.org
Whole thread Raw
In response to Re: Better Upgrades  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
On Mon, Mar 05, 2018 at 11:18:20AM +0100, Daniel Gustafsson wrote:
> > On 02 Mar 2018, at 12:59, Greg Stark <stark@mit.edu> wrote:
> 
> > My feeling is that worrying about in-place binary upgrades today
> > is wasted effort. Already the window for installations where this
> > is useful is narrow -- you have to be big enough that the
> > resources for deploying a second instance is significant but not
> > so big that the downtime and risk is untenable.
> 
> I might be colorblind from $dayjob,

I agree.

> but I don’t think that these installations (data warehouses et.al)
> are that uncommon.

Data warehouses are by no means rare. They also need backups, just as
any other system does, and that means at the very least duplicate
storage on at least one separate node, even if that node can't
actually bring the warehouse back up in the case of a catastrophic
failure of the original warehouse.

> They are also installations that risk staying on an old version due
> to upgrades being non-trivial (not saying that in-place is trivial,
> just that there are places where it may make sense).

I see in-place upgrades as the riskiest of the possible options, and
that's not just in the case of PostgreSQL.  Every other system with
that feature has had catastrophic failures that were impossible to
predict in advance.  That reality turns on the fundamentals of
constructing such systems, to wit:

- They take enormous amounts of deep knowledge to get right.
- The people who have that knowledge are not inclined to doing what
  amounts to an invisible feature.
- They are perforce done as the last thing before a release, often
  blocking other features and holding up the release process as a
  consequence.
- They can never really be tested for corner cases--see above for one
  of the reasons.
- There can be no realistic back-out plan when something goes wrong.

> > I have the feeling that in-place binary upgrades are going to end
> > up sapping developer time
> 
> Having worked on supporting the 8.2->8.3 on-disk format change in
> pg_upgrade for GPDB, I am not arguing against that.  Not at all.

Your experience reflects one of the fundamental problems with those
systems. It wasn't a one-off.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: Flexible configuration for full-text search
Next
From: Etsuro Fujita
Date:
Subject: Re: inserts into partitioned table may cause crash