dave sale <postgres@slipt.net> writes:
> psql: FATAL: could not open relation with OID 3606
> I'm pretty sure the file is there for 3606, but it's another system index from what I can tell:
> postgres=> select oid,* from pg_class where oid=3606;
> oid | relname | relnamespace | reltype | relowner | relam | relfilenode | reltablespace |
relpages| reltuples | reltoastrelid | reltoastidxid | relhasindex | relisshared | relkind | relnatts | relchecks |
reltriggers| relukeys | relfkeys | relrefs | relhasoids | relhaspkey | relhasrules | relhassubclass | relfrozenxid |
relacl| reloptions
>
------+----------------------------+--------------+---------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------+---------+----------+-----------+-------------+----------+----------+---------+------------+------------+-------------+----------------+--------------+--------+------------
> 3606 | pg_ts_parser_prsname_index | 11 | 0 | 10 | 403 | 33505478 | 0 |
2| 1 | 0 | 0 | f | f | i | 2 | 0 | 0
| 0 | 0 | 0 | f | f | f | f | 0 | |
> (1 row)
That's bizarre. A look into the source code says you can only get that
particular error message when the relcache code is unable to find a
pg_class row for OID 3606 ... so how come there is one? My best guess
at the moment is that the row looks valid to an MVCC snapshot but not
under SnapshotNow rules. What do the xmin and xmax fields of that row
contain?
Also, you might be able to get out of this problem (at least far enough
to dump the tables you need) by copying pg_internal.init from an
undamaged database into the damaged one. Better keep the old copy of
the file (if any) in case this makes things worse, though.
regards, tom lane
