Re: [Fwd: Re: Question about pgfsck]

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dan Hrabarchuk <dan(at)kwasar(dot)biz>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: [Fwd: Re: Question about pgfsck]
Date: 2004-10-07 16:55:55
Message-ID: 29736.1097168155@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Dan Hrabarchuk <dan(at)kwasar(dot)biz> writes:
> Is there a FAQ or a HOWTO on recovering from database corruption? If
> not, then I am willing to write it. I will need help getting the
> document together because as much as I google, I come up empty handed.
> ...
> I want to have something that can be easily digested and doesn't require
> advanced knowledge of postgres.

I think this is an impossible goal. The facts of the matter are that it
generally *isn't* easy to get out of a corrupt-data scenario, and it
certainly isn't something that can be reduced to a cookbook recipe that
a novice can follow. If we had bugs with effects as predictable as
that, we would have found them and fixed them long ago. I think every
corruption situation is unique and has to be approached as a fresh
problem.

Part of that feeling stems from the fact that you usually want to try
to identify *why* the corruption occurred, not just fix its immediate
effects, and that almost always requires examining the entrails at a
pretty low level of detail. If you don't find out why it happened then
you have no confidence that it won't happen again.

Don't get me wrong --- I think a HOWTO on this is a fine idea. I'm just
telling you that it's going to have to be a fairly detailed document
that is going to teach the reader quite a bit about postgres internals.

You can collect a lot of material for it by trawling the PG mailing list
archives for old threads in which people were having corruption
problems. Aside from the obvious of "corruption", try looking for
threads mentioning REINDEX, pg_resetxlog, pg_filedump, locating tuples
by ctid, the zero_damaged_pages parameter, memtest86, and badblocks,
as those are the common tools for this sort of activity.

You can search the archives either directly at
http://archives.postgresql.org/ or via Oleg and Teodor's indexer
at http://www.pgsql.ru/db/pgsearch/. I tend to use both as they
seem to have different searching behavior. Google has a good indexer
but a rather incomplete set of PG list archives, so that's usually my
last choice...

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message admin 2004-10-07 18:44:21 Re: problems with pg_dump and pg_restore
Previous Message Dan Hrabarchuk 2004-10-07 16:25:24 [Fwd: Re: Question about pgfsck]