Bruce Momjian wrote:
> depstein(at)alliedtesting(dot)com wrote:
> > I am trying to obtain a binary dump of a small test database where this
> > issue could be reproduced, but so far, no luck. At present, the least
> > such database is 1.5 GB compressed and contains a lot of proprietary
> > info. I would welcome any suggestions on how to do this.
> Your diagnosis is 100% on target, and very perceptive. Because we
> preserve pg_class.relfilenode, if the table has not been rebuilt, for
> example by CLUSTER, the old system the pg_class.oid and
> pg_class.relfilenode are the same, and hence pg_class.oid is preserved
> through pg_class.relfilenode during the migration. If they are
> different, e.g. they ran CLUSTER, pg_upgrade will be wrong because the
> oid has changed, and you will see the errors you are reporting.
> I am inclined to prevent pg_upgrade from migrating any database that
> uses any of these reg* data types, and document this restriction. I
> probably could allow regtype because that pg_type is preserved.
I have applied the attached patch to CVS HEAD and 9.0 that prevent
migration when any reg* data type is used in a user table (except
regtype because pg_type.oid is preserved).
I documented this restriction. Thanks again for the report.
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
+ None of us is going to be here forever. +
Description: text/x-diff (10.7 KB)
In response to
pgsql-bugs by date
|Next:||From: Bruce Momjian||Date: 2010-07-25 03:48:28|
|Subject: Re: pg_upgrade issues|
|Previous:||From: Dave Page||Date: 2010-07-24 08:14:47|
|Subject: Re: installing Postgres 9.0 beta 3 fails on windows 2003 32bit|