depst...@alliedtesting.com wrote: > > 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).
OK, thanks. I was curious about your usage so I could determine how widespread usage of those reg* types is. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs