Thread: Re: [HACKERS] obsolete code in pg_upgrade
On Tue, Aug 22, 2017 at 8:28 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> It seems to me that this code in pg_upgrade/check.c has been useless
> since at least version 9.1:
>
> /* Is it 9.0 but without tablespace directories? */
> if (GET_MAJOR_VERSION(new_cluster.major_version) == 900 &&
> new_cluster.controldata.cat_ver < TABLE_SPACE_SUBDIRS_CAT_VER)
> pg_fatal("This utility can only upgrade to PostgreSQL version
> 9.0 after 2010-01-11\n"
> "because of backend API changes made during
> development.\n");
I think I agree. It seems to me that the version of pg_upgrade
shipped with release N only needs to support upgrades to release N,
not older releases. There's probably room for debate about whether a
pg_upgrade needs to support direct upgrades FROM very old releases,
but we need not decide anything about that right now.
I think you could go ahead and rip out this code, but as it seems like
a non-critical change, -1 for back-patching it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 8/23/17 09:36, Robert Haas wrote: > I think I agree. It seems to me that the version of pg_upgrade > shipped with release N only needs to support upgrades to release N, > not older releases. There's probably room for debate about whether a > pg_upgrade needs to support direct upgrades FROM very old releases, > but we need not decide anything about that right now. > > I think you could go ahead and rip out this code, but as it seems like > a non-critical change, -1 for back-patching it. committed to PG10 and master -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Peter Eisentraut 2017-08-24 <8aa00f15-144e-e793-750e-d1d6876d6a7e@2ndquadrant.com> > On 8/23/17 09:36, Robert Haas wrote: > > I think I agree. It seems to me that the version of pg_upgrade > > shipped with release N only needs to support upgrades to release N, > > not older releases. There's probably room for debate about whether a > > pg_upgrade needs to support direct upgrades FROM very old releases, > > but we need not decide anything about that right now. > > > > I think you could go ahead and rip out this code, but as it seems like > > a non-critical change, -1 for back-patching it. > > committed to PG10 and master This #define seems to be obsolete now as well: src/bin/pg_upgrade/pg_upgrade.h:#define TABLE_SPACE_SUBDIRS_CAT_VER 201001111 Christoph
On 8/25/17 04:00, Christoph Berg wrote: > Re: Peter Eisentraut 2017-08-24 <8aa00f15-144e-e793-750e-d1d6876d6a7e@2ndquadrant.com> >> On 8/23/17 09:36, Robert Haas wrote: >>> I think I agree. It seems to me that the version of pg_upgrade >>> shipped with release N only needs to support upgrades to release N, >>> not older releases. There's probably room for debate about whether a >>> pg_upgrade needs to support direct upgrades FROM very old releases, >>> but we need not decide anything about that right now. >>> >>> I think you could go ahead and rip out this code, but as it seems like >>> a non-critical change, -1 for back-patching it. >> >> committed to PG10 and master > > This #define seems to be obsolete now as well: > src/bin/pg_upgrade/pg_upgrade.h:#define TABLE_SPACE_SUBDIRS_CAT_VER 201001111 fixed, thanks -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services