Re: [Fwd: Re: Question about pgfsck]
От | Tom Lane |
---|---|
Тема | Re: [Fwd: Re: Question about pgfsck] |
Дата | |
Msg-id | 29736.1097168155@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [Fwd: Re: Question about pgfsck] (Dan Hrabarchuk <dan@kwasar.biz>) |
Список | pgsql-admin |
Dan Hrabarchuk <dan@kwasar.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
В списке pgsql-admin по дате отправления: