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.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
