depstein@alliedtesting.com wrote:
> > 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.
> >
> > 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.
>
> 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 table that pulled the trigger (this is the case for
> some of our uses).
OK, thanks. I was curious about your usage so I could determine how
widespread usage of those reg* types is.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
