Re: Detecting corrupted pages earlier

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Detecting corrupted pages earlier
Дата
Msg-id 6086.1049056148@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Detecting corrupted pages earlier  (Kevin Brown <kevin@sysexperts.com>)
Ответы Re: Detecting corrupted pages earlier
Список pgsql-hackers
Kevin Brown <kevin@sysexperts.com> writes:
> Tom Lane wrote:
>> Basically, one should only turn this variable on after giving up on the
>> possibility of getting any data out of the broken page itself.  It would
>> be folly to run with it turned on as a normal setting.

> This statement should *definitely* go into the documentation for the
> option, then...

Here's what I put in --- feel free to suggest better wording.

ZERO_DAMAGED_PAGES (boolean)
    Detection of a damaged page header normally causes PostgreSQL to    report an error, aborting the current
transaction.Setting    zero_damaged_pages to true causes the system to instead report a    warning, zero out the
damagedpage, and continue processing. This    behavior <emphasis>will lose data</>, namely all the rows on the
damagedpage. But it allows you to get past the error and retrieve    rows from any undamaged pages that may be present
inthe table. So    it is useful for recovering data if corruption has occurred due to    hardware or software error.
Thedefault setting is off, and it can    only be changed by a superuser.
 

        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: CVS head doesn't compile
Следующее
От: Tom Lane
Дата:
Сообщение: Re: updateable cursors & visibility