Re: pg_upgrade issues

> Bruce Momjian wrote:
> > depstein@alliedtesting.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.
>=20
> 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).
>=20
> I documented this restriction.  Thanks again for the report.

Thank you for the explanation and the swift action.

I just want to note that one reason regclass may be used in user tables (as=
 opposed to, say, regtype) is that in PL/pgSQL trigger procedures there is =
a special variable TG_RELID, which provides a convenient reference to the t=
able that pulled the trigger (this is the case for some of our uses).

Dmitry