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

From Matthew T. O'Connor
Subject Re: Block-level CRC checks
Date
Msg-id 4921CDD8.8090204@zeut.net
Whole thread Raw
In response to Re: Block-level CRC checks  (Aidan Van Dyk <aidan@highrise.ca>)
Responses Re: Block-level CRC checks  (Aidan Van Dyk <aidan@highrise.ca>)
List pgsql-hackers
Aidan Van Dyk wrote:
> * Greg Stark <greg.stark@enterprisedb.com> [081117 03:54]:
>> I thought of saying that too but it doesn't really solve the problem.  
>> Think of what happens if someone sets a hint bit on a dirty page.
> 
> If the page is dirty from a "real change", then it has a WAL backup block
> record already, so the torn-page on disk is going to be fixed with the wal
> replay ... *because* of the torn-page problem already being "solved" in PG.
> You don't get the hint-bits back, but that's no different from the current
> state.  But nobody's previously cared if hint-bits wern't set on WAL replay.


What if all changes to a page (even hit bits) are WAL logged when 
running with Block-level CRC checks enables, does that make things 
easier?  I'm sure it would result in some performance loss, but anyone 
enabling Block Level CRCs is already trading some performance for safety.

Thoughts?


pgsql-hackers by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: Compiling on HP-UX 10.20 fails
Next
From: Peter Eisentraut
Date:
Subject: Re: xmlconcat as variadic function