From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Heiko Wundram <modelnine(at)modelnine(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Somewhat automated method of cleaning table of corrupt records for pg_dump |
Date: | 2012-10-22 07:05:57 |
Message-ID: | 5084F055.70706@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 10/19/2012 10:31 PM, Heiko Wundram wrote:
> Hey!
>
> I'm currently in the situation that due to (probably) broken memory in a
> server, I have a corrupted PostgreSQL database. Getting at the data
> that's in the DB is not time-critical (because backups have restored the
> largest part of it), but I'd still like to restore what can be restored
> from the existing database to fill in the remaining data. VACUUM FULL
> runs successfully (i.e., I've fixed the blocks with broken block
> headers, removed rows that have invalid OIDs as recorded by the VACUUM,
> etc.), but dumping the DB from the rescue system (which is PostgreSQL
> 8.3.21) to transfer it to another still fails with "invalid memory alloc
> request size 18446744073709551613", i.e., most probably one of the TEXT
> colums in the respective tables contains invalid sizings.
Working strictly with a *copy*, does REINDEXing then CLUSTERing the
tables help? VACCUM FULL on 8.3 won't rebuild indexes, so if index
damage is the culprit a reindex may help. Then, if CLUSTER is able to
rewrite the tables in index order you might be able to recover.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Nikolay Samokhvalov | 2012-10-22 08:29:03 | Bruce Momjian's talk online/recorded in Moscow |
Previous Message | Craig Ringer | 2012-10-22 07:02:22 | Re: Streaming Replication Server Crash |