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
>
