From: | Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Detecting corrupted pages earlier |
Date: | 2003-02-17 19:48:43 |
Message-ID: | bxyadgu4rj8.fsf@datafix.CS.Berkeley.EDU |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
Tom> Postgres has a bad habit of becoming very confused if the
Tom> page header of a page on disk has become corrupted. In
Tom> particular, bogus values in the pd_lower field tend to make
I haven't read this piece of pgsql code very carefully so I apologize
if what I suggest is already present.
One "standard" solution to handle disk page corruption is the use of
"consistency" bits.
The idea is that the bit that starts every 256th byte of a page is a
consistency bit. In a 8K page, you'd have 32 consistency bits. If the
page is in a "consistent" state, then all 32 bits will be either 0 or
1. When a page is written to disk, the "actual" bit in each c-bit
position is copied out and placed in the header (end/beginning) of the
page. With a 8K page, there will be one word that contains the
"actual" bit. Then the c-bits are all either set or reset depending on
the state when the page was last read: if on read time the c-bits were
set, then on write time they are reset. So when you read a page, if
some of the consistency bits are set and some others are reset then
you know that there was a corruption.
This is of course based on the assumption that most disk arms manage
to atomically write 256 bytes at a time.
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2003-02-17 20:14:02 | Re: new Configuration patch, implements 'include' |
Previous Message | Tom Lane | 2003-02-17 19:41:03 | Detecting corrupted pages earlier |