Re: Enabling Checksums

From: Jim Nasby <jim(at)nasby(dot)net>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Greg Smith <greg(at)2ndQuadrant(dot)com>, Daniel Farina <daniel(at)heroku(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Enabling Checksums
Date: 2013-03-05 00:15:24
Message-ID: 5135391C.2050103@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/4/13 5:20 PM, Craig Ringer wrote:
> On 03/05/2013 04:48 AM, Jeff Davis wrote:
>> We would still calculate the checksum and print the warning; and then
>> pass it through the rest of the header checks. If the header checks
>> pass, then it proceeds. If the header checks fail, and if
>> zero_damaged_pages is off, then it would still generate an error (as
>> today).
>>
>> So: ignore_checksum_failures = on|off ?
> That seems reasonable to me. It would be important to document clearly
> in postgresql.conf and on the docs for the option that enabling this
> option can launder data corruption, so that blocks that we suspected
> were damaged are marked clean on rewrite. So long as that's clearly
> documented I'm personally quite comfortable with your suggestion, since
> my focus is just making sure I can get a DB back to a fully operational
> state as quickly as possible when that's necessary.

I replied to this somewhere else in the thread when I over-looked Jeff's original post, so sorry for the noise... :(

Would it be better to do checksum_logging_level = <valid elog levels> ? That way someone could set the notification to anything from DEBUG up to PANIC. ISTM the default should be ERROR.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2013-03-05 00:22:30 Re: Enabling Checksums
Previous Message Greg Smith 2013-03-04 23:34:13 Re: Enabling Checksums