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.
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 |