Re: Better Upgrades

From: David Fetter <david(at)fetter(dot)org>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Greg Stark <stark(at)mit(dot)edu>, Craig Ringer <craig(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Better Upgrades
Date: 2018-03-05 12:59:33
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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(at)mit(dot)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
> 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
- 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.

David Fetter <david(at)fetter(dot)org>
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres:

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2018-03-05 13:00:58 Re: inserts into partitioned table may cause crash
Previous Message Aleksander Alekseev 2018-03-05 12:59:21 Re: Flexible configuration for full-text search