Re: pg_upgrade relation OID mismatches
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade relation OID mismatches |
Дата | |
Msg-id | 201111222329.pAMNTDM19052@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade relation OID mismatches (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: pg_upgrade relation OID mismatches
|
Список | pgsql-hackers |
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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: