Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade issues

From: <depstein(at)alliedtesting(dot)com>
To: <bruce(at)momjian(dot)us>
Cc: <pgsql-bugs(at)postgresql(dot)org>, <pgagarinov(at)alliedtesting(dot)com>
Subject: Re: pg_upgrade issues
Date: 2010-07-26 12:05:24
Message-ID: 29F36C7C98AB09499B1A209D48EAA615B49FD1866A@mail2a.alliedtesting.com (view raw or flat)
Thread:
Lists: pgsql-bugs
> 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.

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

In response to

Responses

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2010-07-26 12:18:19
Subject: Re: pg_upgrade issues
Previous:From: mileDate: 2010-07-26 09:58:05
Subject: BUG #5571: global hash %_SHARED is not declared as global in the new version

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group