Unanswered: Emergency Restore Problem with psql from pg_dumpall
I'm having what should be a simple task that is failing. I have some friends in Africa who are literally dependent on me getting this DB back online. The problem started when the power surged (Its central Africa - no surprise) and the production DB didn't want to come back up. It had a "failed to re-find parent key in index ..."
I was forced to do a pg_resetxlog as their backup didn't work. (Always the case when you need it most!)
After bringing up the db with pg_resetxlog, I did an immediate pg_dumpall to a target file. Previous to this pg_resetxlog I tarballed the entire postgres directories off to another target.
The pd_dumpall worked fine.
I dropped the database in question, then did a vacuum analyze on the only remaining postgres db several times. There wasn't much in there and the db could successfully start and stop with this it.
I then recreated the db from dump script then ran a:
psql -f dumpfile.sql
It restores the schema objects fine for the db. It gets about 43GB into the 50GB target when it just seems to fail.
Then only indication I have is from the postgres log:
checkpoints are occurring too frequently ...
could not receive data from client: Connection reset by peer
unexpected EOF on client connection
Its Postgres 8.4 on Ubuntu 10.04
The situation is truly an emergency as those folks I'm trying to help are actually in jeopardy, no kidding as this is a government db and its, well Africa.
I've tried many different approaches to the restore, including nohup, screen, etc. and it seems like it wants to quit at the same point, indicating it's something with the either the target DB needing something or the exported dump from pg_dumpall having the problem.
Any suggestions would be greatly appreciated. I can restore the original corrupt DB from the tarball and try re-exporting. The original error was about an index so I could reindex the original corrupt db as well.