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

Re: Block-level CRC checks

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>,Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>,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 18:10:34
Message-ID: 20081002181034.GC16893@yugib.highrise.ca (view raw or flat)
Thread:
Lists: pgsql-hackers
* Jonah H. Harris <jonah(dot)harris(at)gmail(dot)com> [081002 14:01]:
> On Thu, Oct 2, 2008 at 1:58 PM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> >> On recovery after a torn-page write, won't the recovery of the
> >> full_page_write WAL + WAL changes get us back to the page as it was
> >> before the buffer+checksum+write?
> >
> > Hint bit setting doesn't trigger a WAL record.
> 
> Hence, no page image is written to WAL for later use in recovery.

OK.  Got it...  The block is dirty (only because of hint bits).  write
starts, crash, torn page, recovery doesn't "fix" the torn page...
because it's never been changed (according WAL), so on next read...

Without the CRC it doesn't matter, because the only change was
hint-bits, so the page is half-old+half-new, but new == old+only
hint-bits...

Because ther'es no WAP. the torn page will be read next time that buffer
is needed...

a.

-- 
Aidan Van Dyk                                             Create like a god,
aidan(at)highrise(dot)ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2008-10-02 18:15:49
Subject: Re: FSM rewrite committed, loose ends
Previous:From: Jonah H. HarrisDate: 2008-10-02 18:04:56
Subject: Re: Block-level CRC checks

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