Re: index "pg_authid_rolname_index" is not a btree

Tom,

Thank you.

> Alvaro was right --- you've got damage in the system catalogs, not just
> their indexes. This looks like missing entries in pg_amop.

postgres -D data mydb

PostgreSQL stand-alone backend 8.1.9
backend> select * from pg_amop
1: amopclaid (typeid = 26, len = 4, typmod = -1, byval = t)
2: amopsubtype (typeid = 26, len = 4, typmod = -1, byval = t)
3: amopstrategy (typeid = 21, len = 2, typmod = -1, byval =
t)
4: amopreqcheck (typeid = 16, len = 1, typmod = -1, byval =
t)
5: amopopr (typeid = 26, len = 4, typmod = -1, byval = t)
----

pg_amop in mydb contains 5 rows.
pg_amop in template1 database contains large number of rows.
mydb does not contain user-defined operators.

How to repair pg_amop in mydb ?

> (You did
> say you reindexed all the system catalogs, right? If not it's possible
> this is only index damage, but I'm not very hopeful.)

reindex system mydb
reindex database mydb

complete without errors.

> I suspect that if you did get to the point of being able to run pg_dump
> without error, you'd find just as much damage to the user data. I'm
> afraid this database is toast and you should write it off as a learning
> experience. Hardware fails, you need backups.

Backup is 4.2 GB and is corrupted after 2 GB as I described in other thread.
Also, backup is too old.
Most of backup size contains few big tables which are not required to
recover.
I ran truncate commands for those tables. This reduces whole data
directory size to 1.2 GB in uncompressed form.

I know which tables contain data to be recovered.

How to dump those tables out ?

Andrus.