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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-10-02 18:15:49 | Re: FSM rewrite committed, loose ends |
Previous Message | Jonah H. Harris | 2008-10-02 18:04:56 | Re: Block-level CRC checks |