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