Re: Fast default stuff versus pg_upgrade - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Fast default stuff versus pg_upgrade
Date
Msg-id CAKFQuwbHZMfw308Wq+B_dKjfKCqOvjuK-H6G+tiTpwE8pCb-0Q@mail.gmail.com
Whole thread Raw
In response to Re: Fast default stuff versus pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fast default stuff versus pg_upgrade
List pgsql-hackers
On Tue, Jun 19, 2018 at 9:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
The problem here is that that function does not exist in 11beta1.
Since adding the "incoming" function is certainly going to require
initdb, we have to be able to dump from the server as it now stands,
or we'll be cutting existing beta testers adrift.

I was under the impression that we don't promise to support a "v10 -> beta -> rc -> final" upgrade path; instead, once final is released people would be expected to upgrade "v10 -> v11".  Under that condition requiring users to do "v10 -> beta2" instead of "beta1 -> beta2", while annoying, is well within the realm of possibility and expectation.

David J.

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Fast default stuff versus pg_upgrade
Next
From: Jeevan Ladhe
Date:
Subject: Re: ToDo: show size of partitioned table