From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Cc: | David Fetter <david(at)fetter(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Better Upgrades |
Date: | 2018-02-06 03:13:03 |
Message-ID: | CAMsr+YGjbD-xUzQ_WNicamRuDFiCzzr3HBu5Y93xCDxQ_3gurA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Support for reading prior version catalogs in-place is what I see as the
user-friendly end goal. Just start Pg12 on top of a pg11 datadir with the
--allow-upgrade flag and you're done.
But I don't think I'm any keener to do the drudgery required to implement
it than anyone else is... and I share others' concerns about the
maintenance burden imposed, impact on future catalog change freedom, etc.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2018-02-06 03:26:51 | Re: [HACKERS] [PATCH] Lockable views |
Previous Message | Robert Haas | 2018-02-06 03:00:44 | Re: [HACKERS] [PATCH] Lockable views |