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

Re: [SPAM?]: Re: Block-level CRC checks

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql(at)mohawksoft(dot)com, Decibel! <decibel(at)decibel(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [SPAM?]: Re: Block-level CRC checks
Date: 2008-10-02 08:28:57
Message-ID: 1222936137.12899.5.camel@huvostro (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, 2008-10-02 at 09:35 +0300, Heikki Linnakangas wrote:
> Jonah H. Harris wrote:
> > Rather than potentially letting this slide past 8.4, I threw together
> > an extremely quick-hack patch at the smgr-layer for block-level
> > checksums.
> 
> One hard problem is how to deal with torn pages with non-WAL-logged 
> changes. Like heap hint bit updates, killing tuples in index pages 
> during a scan, and the new FSM pages.

Hit bit updates and killing tuples in index pages during a scan can
probably be brute-forced quite cheaply after we find a CRC mismatch.
Not sure about new FSM pages.

> Currently, a torn page when writing a hint-bit-updated page doesn't 
> matter, but it would break the checksum.

Another idea is to just ignore non-WAL-logged bits when calculating
CRC-s, by masking them out before adding corresponding bytes to CRC.

This requires page-type aware CRC functions and is more expensive to
calculate. How much more expensive is something that only testing can
tell. Probably not very much, as everything needed should be in L1
caches already.

---------------
Hannu



In response to

pgsql-hackers by date

Next:From: Zdenek KotalaDate: 2008-10-02 08:32:42
Subject: Re: FSM rewrite committed, loose ends
Previous:From: Dimitri FontaineDate: 2008-10-02 08:27:22
Subject: Re: FSM rewrite committed, loose ends

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