From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Mach <mach(dot)robert(at)gmail(dot)com> |
Subject: | Re: Proposal: Integrity check |
Date: | 2008-01-25 18:03:10 |
Message-ID: | 479A245E.9080506@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-01-25 18:49:54 | Re: Thoughts about bug #3883 |
Previous Message | Decibel! | 2008-01-25 17:49:34 | Re: Truncate Triggers |