Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed

Rural Hunter <ruralhunter@gmail.com> writes:
> # 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)

Well, that's even stranger, because (1) information_schema.sql_features
ought to have a toast table in either version, and (2) neither pg_dump
nor pg_upgrade ought to be attempting to dump or transfer that table.

I wonder whether you dropped and recreated the information_schema in
the lifetime of this database?  We have recommended doing that in the
past, IIRC.  Could such a thing have confused pg_dump?
        regards, tom lane