> Bruce Momjian wrote: > > depst...@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). Dmitry -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
