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

Re: Block-level CRC checks

From: Decibel! <decibel(at)decibel(dot)org>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Brian Hurt <bhurt(at)janestcapital(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-10-02 22:56:16
Message-ID: 025DDAC5-8EB7-4164-B78A-02B9E379E341@decibel.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Oct 2, 2008, at 3:18 PM, Alvaro Herrera wrote:
> I have to admit I don't remember exactly how it worked :-)  I think  
> the
> idea was avoiding setting the page dirty until a certain number of  
> hint
> bit setting operations had been done (which I think means it's not
> useful for the present purpose).


Well, it would be useful if whenever we magically decided it was time  
to write out a page that had only hint-bit updates we generated WAL,  
right? Even if it was just a no-op WAL record to ensure we had the  
page image in the WAL.

BTW, speaking of torn pages... I've heard that there's some serious  
gains to be had by turning full_page_writes to off, but I've never  
even dreamed of doing that because I've never seen any real sure-fire  
way to check that your hardware can't write torn pages. But if we  
have checksums enabled and checked the checksums on a block the first  
time we touched it during recovery, we'd be able to detect torn  
pages, yet still recover. That would help show that torn pages aren't  
possible in a particular environment (though unfortunately I don't  
think there's any way to actually prove that they're not).
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828


In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2008-10-02 23:07:55
Subject: Re: [PATCHES] Infrastructure changes for recovery
Previous:From: Simon RiggsDate: 2008-10-02 22:42:59
Subject: Re: Transaction Snapshots and Hot Standby

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