Re: Proposal: Integrity check - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: Proposal: Integrity check
Date
Msg-id 479A245E.9080506@sun.com
Whole thread Raw
In response to Re: Proposal: Integrity check  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal: Integrity check
List pgsql-hackers
Tom Lane wrote:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> I would like to make following modification:
> 
>> 1) Add ReadBuffer_noerror (recommend me better name) function which will 
>> accept damaged page without Error. This page will be marked as corrupted 
>> and when ReadBuffer will touch this page then it will be handled in 
>> standard way.
> 
> This seems like a pretty horrid idea.  Bad pages shouldn't be allowed to
> get into shared buffers in the first place.  Why not have the checking
> logic operate outside shared buffers?

It currently works outside the shared buffers, but I afraid about 
collision due to parallel read and write access on one block. I'm not 
sure if parallel write(8k) and read(8k) is synchronized by kernel/fs or 
not. If not it should generates false positive results. If yes than I'm 
happy :-) with outside processing.


>> 3) Add PageHeaderIsValid check also for write operation
> 
>> In production it should catch problem with memory or software bugs. In 
>> development it should catch memory overwriting.
> 
> Is there any evidence whatsoever to demonstrate that this is worth the
> cycles it will eat?

Alex from clickware tries this modification to catch their problem with 
random damaged database. But, I don't have any result yet.
    Zdenek


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal: Integrity check
Next
From: Simon Riggs
Date:
Subject: Re: Truncate Triggers