From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | "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 |
Date: | 2018-03-02 11:59:06 |
Message-ID: | CAM-w4HMz6NX-hRBAGonRtSPebYjK6tc2JysJt3Wqu=yfiQF5cw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6 February 2018 at 03:13, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 6 February 2018 at 09:51, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>>
>> On 02/05/2018 04:09 PM, David Fetter wrote:
>>
>>> Does this seem worth coding up in its current form?
>>
>> No. The pg_upgrade utility is awesome and I have commended Bruce on
>> multiple occasions about his work with it. That being said, the
>> "solution" is to support in-place upgrades and our work should be toward
>> that.
>
> Yeah. Streaming upgrade is useful, but IMO it's a workaround for upgrade
> issues more than a solution in its self. Useful for people who want a
> conservative upgrade, but not that big a win. Sure you'd like to be able to
> downgrade again if it doesn't go right, but that requires a two-way sync,
> which introduces its own problems and failure modes.
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 have the feeling that in-place
binary upgrades are going to end up sapping developer time and imposes
awkward constraints on the system for a legacy feature users are
recommended to never use anyways.
Running distributed systems with replication used to be a niche "HA"
solution. Today it's the norm to have configuration management systems
that automatically provision and deploy however many replicas you want
and set up repmgr/consul/whatever to do automatic failovers. In that
environment creating a couple new logical replicas using the new
version and doing a failover becomes an easy choice.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2018-03-02 12:18:02 | Re: 2018-03 CFM |
Previous Message | Magnus Hagander | 2018-03-02 11:47:56 | Re: 2018-03 CFM |