Re: Database corruption help

Cheers, i'll give it ago. I'm probably going to do a full restore over 
the weekend while i can shut things down without too many complaints...

I can save any of the files if you are interested in them later on...

JOHN

Tom Lane wrote:
> John Lister <john.lister-ps@kickstone.com> writes:
>   
>> Any help would be appreciated as the pg_class table is constantly 
>> growing which i'm guessing is going to start to affect performance 
>> fairly soon. I'd like to avoid a full restore from backup if possible.
>>     
>
> BTW, what I would recommend as a recovery action is to zero out that
> page of pg_class while the postmaster is stopped.  We know that none
> of those rows are useful to you, and there shouldn't be any index
> entries pointing at them (since they're all HOT tuples), so at least
> in theory that won't cause any damage.  Then you can try another
> VACUUM FULL and see if there are any more pages with, er, issues.
>
> If you're on a machine that has /dev/zero then something like this
> should work:
>
> dd bs=8k count=1 seek=15538 conv=notrunc if=/dev/zero of=$PGDATA/base/16392/1259
>
> but it'd be a good idea to save a copy of the target file so you can try
> again if you mess up.
>
> Also, it'd really be prudent to do a dump, initdb, reload once you
> get to a point where pg_dump succeeds without complaints.  We don't
> have any good way to know what other corruption might be lurking
> undetected.
>
>             regards, tom lane
>