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.
