Re: Block-level CRC checks

I think I'm missing something...

In this patch, I see you writing WAL records for hint-bits (bufmgr.c
FlushBuffer). But doesn't XLogInsert then make a "backup block" record (unless
it's already got one since last checkpoint)?

Once there's a backup block record, the torn-page problem that causes the whole
CRCs to not validate, isn't it? On crash/recovery, you won't read this torn
block because the WAL log will have the old backup + any possible updates to
it...

Sorry if I'm missing something very obvious...

a.

* Alvaro Herrera <alvherre(at)commandprompt(dot)com> [081113 13:08]:

> I see.
>
> Since our CRC implementation is a simple byte loop, and since ItemIdData
> fits in a uint32, the attached patch should do mostly the same by
> copying the line pointer into a uint32, turning off the lp_flags, and
> summing the modified copy.
>
> This patch is also skipping pd_special and the unused area of the page.
>
> I'm still testing this; please beware that this likely has an even
> higher bug density than my regular patches (and some debugging printouts
> as well).
>
> While reading the pg_filedump code I noticed that there's a way to tell
> the different index pages apart, so perhaps we can use that to be able
> to checksum the special space as well.

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