Re: pg_upgrade relation OID mismatches

Peter Eisentraut wrote:
> On tis, 2011-11-22 at 15:42 -0500, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > I thought these were fixed a while ago, but I'm still seeing these when
> > > upgrading from master to self (using testing script sent in a while
> > > ago). This is completely reproducible. What's happening?
> > >
> > > ...
> > > Restoring user relation files
> > > /home/peter/devel/postgresql/git/postgresql/contrib/pg_upgra
> > > Mismatch of relation OID in database "regression": old OID 16701, new OID 16689
> > > Failure, exiting
> >
> > Yes, I certainly thought they were all addressed. What object is 16701
> > in the old database? Anything unusual about it? This is saying the
> > relation oid was not preserved.
>
> It came in with the range types feature:
>
> + psql -d regression -x -c 'select * from pg_class where oid = 16701'
> -[ RECORD 1 ]--+----------------
> relname | test_range_gist
> relnamespace | 2200
> reltype | 16703
> reloftype | 0
> relowner | 10
> relam | 0
> relfilenode | 16701
> reltablespace | 0
> relpages | 33
> reltuples | 6200
> relallvisible | 33
> reltoastrelid | 16704
> reltoastidxid | 0
> relhasindex | t
> relisshared | f
> relpersistence | p
> relkind | r
> relnatts | 1
> relchecks | 0
> relhasoids | f
> relhaspkey | f
> relhasrules | f
> relhastriggers | f
> relhassubclass | f
> relfrozenxid | 1627
> relacl |
> reloptions |

OK, that is a heap table. My only guess is that the heap is being
created without binary_upgrade_next_heap_pg_class_oid being set.
Looking at the code, I can't see how the heap could be created without
this happening. Another idea is that pg_dumpall isn't output the proper
value, but again, how is this data type different from the others.

I will try to research this further.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +