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

Re: Block-level CRC checks

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, 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 14:43:18
Message-ID: 1259678598.13774.13487.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 2009-12-01 at 15:30 +0200, Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > What might be interesting is to report CRC mismatches if the database
> > was shut down cleanly previously;  I think in those cases we shouldn't
> > have torn pages.
> 
> Unfortunately that's not true. You can crash, leading to a torn page,
> and then start up the database and shut it down cleanly. The torn page
> is still there, even though the last shutdown was a clean one.

There seems to be two ways forwards: journalling or fsck.

We can either

* WAL-log all changes to a page (journalling) (8-byte overhead)

* After a crash disable CRC checks until a full database scan has either
re-checked CRC or found CRC mismatch, report it in the LOG and then
reset the CRC. (fsck) (8-byte overhead)

Both of which can be optimised in various ways.

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. 

-- 
 Simon Riggs           www.2ndQuadrant.com


In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-12-01 14:43:30
Subject: Re: CommitFest status/management
Previous:From: Tom LaneDate: 2009-12-01 14:42:28
Subject: Re: CommitFest status/management

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