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
