Re: Block-level CRC checks - Mailing list pgsql-hackers

From Albe Laurenz
Subject Re: Block-level CRC checks
Date
Msg-id D960CB61B694CF459DCFB4B0128514C202901A88@exadv11.host.magwien.gv.at
Whole thread Raw
In response to Re: Block-level CRC checks  ("Jonah H. Harris" <jonah.harris@gmail.com>)
List pgsql-hackers
Jonah H. Harris wrote:
>>>> I'd like to submit this for 8.4, but I want to ensure that -hackers
>>>> at large approve of this feature before starting serious coding.
>>>
>>> IMHO, this is a functionality that should be enabled by default (as it
>>> is on most other RDBMS).  It would've prevented severe corruption in
>>
>> What other RDMS have it enabled by default?
>
> Oracle and (I belive) SQL Server >= 2005

References:
http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams040.htm#CHDDCEIC
http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/initparams046.htm#sthref130

Oracle claims that it introduces only 1% to 2% overhead.

Actually I suggested the same feature for 8.3:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg01003.php

It was eventually rejected because the majority felt that it
would be a small benefit (only detects disk corruption and not
software bugs) that would not justify the overhead and the
additional code.

Incidently, Oracle also has a parameter DB_BLOCK_CHECKING
that checks blocks for logical consistency. This is OFF by default,
but Oracle recommends that you activate it if you can live with
the performance impact.

Yours,
Laurenz Albe


pgsql-hackers by date:

Previous
From: Paul Schlie
Date:
Subject: Re: Block-level CRC checks
Next
From: Heikki Linnakangas
Date:
Subject: Re: WAL recovery is broken by FSM patch