|From:||Daniel Gustafsson <daniel(at)yesql(dot)se>|
|To:||Greg Stark <stark(at)mit(dot)edu>|
|Cc:||Craig Ringer <craig(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Better Upgrades|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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, but I don’t think that these installations
(data warehouses et.al) are that uncommon. 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 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.
|Next Message||Tomas Vondra||2018-03-05 10:19:05||Re: [HACKERS] [PATCH] Incremental sort|
|Previous Message||Magnus Hagander||2018-03-05 10:09:02||Re: Online enabling of checksums|