Re: Detecting corrupted pages earlier

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

In response to

Browse pgsql-hackers by date

  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