Re: Database corruption help

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Lister <john(dot)lister-ps(at)kickstone(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Database corruption help
Date: 2009-02-13 16:28:28
Message-ID: 3304.1234542508@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

John Lister <john(dot)lister-ps(at)kickstone(dot)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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Roger Ging 2009-02-13 17:20:00 Vacuum wait time problem
Previous Message Tom Lane 2009-02-13 16:19:00 Re: Database corruption help

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Chernow 2009-02-13 17:06:09 Re: PQinitSSL broken in some use casesf
Previous Message Jaime Casanova 2009-02-13 16:24:46 Re: Updates of SE-PostgreSQL 8.4devel patches (r1530)