On 6 February 2018 at 03:13, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 6 February 2018 at 09:51, Joshua D. Drake <jd@commandprompt.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
