Skip site navigation (1) Skip section navigation (2)

Re: Block-level CRC checks

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2009-12-01 18:05:47
Message-ID: 200912011805.nB1I5lo02767@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Simon Riggs wrote:
> Also, we might
> 
> * Put all hint bits in the block header to allow them to be excluded
> more easily from CRC checking. If we used 3 more bits from
> ItemIdData.lp_len (limiting tuple length to 4096) then we could store
> some hints in the item pointer. HEAP_XMIN_INVALID can be stored as
> LP_DEAD, since that will happen very quickly anyway. 

OK, here is another idea, maybe crazy:

When we read in a page that has an invalid CRC, we check the page to see
which hint bits are _not_ set, and we try setting them to see if can get
a matching CRC.  If there no missing hint bits and the CRC doesn't
match, we know the page is corrupt.  If two hint bits are missing, we
can try setting one and both of them and see if can get a matching CRC. 
If we can, the page is OK, if not, it is corrupt.

Now if 32 hint bits are missing, but could be based on transaction
status, then we would need 2^32 possible hint bit combinations, so we
can't do the test and we just assume the page is valid.

I have no idea what percentage of corruption this would detect, but it
might have minimal overhead because the overhead only happens when we
detect a non-matching CRC due to a crash of some sort.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-12-01 18:10:03
Subject: Re: Deleted WAL files held open by backends in Linux
Previous:From: Joshua D. DrakeDate: 2009-12-01 18:02:07
Subject: Re: Block-level CRC checks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group