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.