Re: Somewhat automated method of cleaning table of corrupt records for pg_dump

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

In response to

Responses

Browse pgsql-general by date

  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