Re: pg_upgrade from 9.1.3 to 9.2 failed - Mailing list pgsql-admin
From | Rural Hunter |
---|---|
Subject | Re: pg_upgrade from 9.1.3 to 9.2 failed |
Date | |
Msg-id | 505557CD.8090304@gmail.com Whole thread Raw |
In response to | Re: pg_upgrade from 9.1.3 to 9.2 failed (Bruce Momjian <bruce@momjian.us>) |
List | pgsql-admin |
于 2012/9/16 2:06, Bruce Momjian 写道: > On Sat, Sep 15, 2012 at 11:40:06AM +0800, Rural Hunter wrote: >>>>> The check is to make sure that once we have created all the user schema >>>>> details in the new cluster, that there are the same number of objects in >>>>> the new and old databases. >>>>> >>>>> Obviously there are a different number in your case here, but I don't >>>>> know why those would be different, and in fact, because we have never >>>>> hit this, there isn't even any debug output that shows the source of the >>>>> difference. >>>>> >>>>> If I send you a patch can you compile it and send back the debug output >>>>> it produces? >>>>> >>>> Yes sure, I will try to compile and retest with it. >>> Actually, I have a simpler idea. At the point where it fails, you can >>> run pg_dump --schema-only on the testdb database in the old and new >>> cluster and then diff those output files and email the result to us; it >>> should show the mismatch. I am not sure if the dumps will output the >>> objects in the same order, it might. >>> >> diff attached. > OK, I see many new ALTER TABLE commands, but nothing that would cause a > difference in relation count. > > Attached is a patch that will return the OID of the old/new mismatched > entries. Please research the pg_class objects on the old/new clusters > that have the mismatch and let me know. It might be something that > isn't in the old cluster, or not in the new cluster. > I ran the pg_upgrade with the patch and found the problematic object is a toast object. Copying user relation files /raid/pgsql/base/6087920/6088238 Mismatch of relation OID in database "forummon": old OID 16439148, new OID 16439322 In old cluster: # select * from pg_class WHERE oid=16439148; relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode | reltablespace | relpages | reltuples | reltoastrelid | reltoastidxid | relhasindex | relisshared | relpersistence | relkind | relnatts | relchecks | relhasoids | relhaspkey | relhasrules | relhastriggers | relhassubclass | relfrozenxid | relacl | reloptions -------------------+--------------+----------+-----------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------+----------------+---------+----------+-----------+------------+------------+-------------+----------------+----------------+--------------+--------+------------ pg_toast_16439145 | 99 | 16439149 | 0 | 10 | 0 | 16439148 | 0 | 0 | 0 | 0 | 16439150 | t | f | p | t | 3 | 0 | f | t | f | f | f | 630449585 | | (1 row) But it doesn't exist in new cluster: select * from pg_class WHERE oid=16439148; relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode | reltablespace | relpages | reltuples | relallvisible | reltoastrelid | reltoastidxid | relhasindex | relisshared | relpersistence | relkind | relnatts | relchecks | relhasoids | relhaspkey | relhasrules | relhastriggers | relhassubclass | relfrozenxid | relacl | reloptions ---------+--------------+---------+-----------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+---------------+-------------+-------------+----------------+---------+----------+-----------+------------+------------+-------------+----------------+----------------+--------------+--------+------------ (0 rows)
pgsql-admin by date: