Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed - Mailing list pgsql-hackers
From | Rural Hunter |
---|---|
Subject | Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed |
Date | |
Msg-id | 50567E60.2000005@gmail.com Whole thread Raw |
In response to | Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed (Bruce Momjian <bruce@momjian.us>) |
Responses |
Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed
|
List | pgsql-hackers |
于2012年9月17日 1:17:46,Bruce Momjian写到: > On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote: >>> 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) > > [ Thread moved to hackers list.] > > OK, this is exactly what I wanted to see, and it explains why pg_dump > didn't show it. Can you find out what table references this toast > table? Try this query on the old cluster: > > select oid, * from pg_class WHERE reltoastrelid = 16439148; > > I believe it will have an oid of 16439145, or it might not exist. > # select oid, * from pg_class WHERE reltoastrelid = 16439148; oid | 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 ----------+--------------+--------------+----------+-----------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------+----------------+---------+----------+-----------+------------+------------+-------------+----------------+----------------+--------------+-----------------------------------------+------------16439145 |sql_features | 16438995 | 16439147 | 0 | 10 | 0 | 16439145 | 0 | 0 | 0 | 16439148 | 0 | f | f | p | r | 7 | 0 | f | f | f | f | f | 630449585 | {postgres=arwdDxt/postgres,=r/postgres} | (1 row) It's not a table. I haven't seen this name before. not sure why it exists. So what's the next thing I can do?
pgsql-hackers by date: