Re: How to make sure I don't write a corrupt page to db when I checkpoint?

From: Brian Selzer <brian_at_selzer-software.com>
Date: Sun, 01 Jul 2007 13:30:05 GMT
Message-ID: <x%Nhi.16529$2v1.7977_at_newssvr14.news.prodigy.net>


"Sune" <sune_ahlgren_at_hotmail.com> wrote in message news:1183277724.576790.246740_at_i38g2000prf.googlegroups.com...
> Hi all!
>
> I'm looking into designing an in-memory DB. Before I start, there are
> several things I must have figured out. Among those things is a
> technique to use to make sure that I don't write a corrupt page to db
> when I checkpoint. How do I make sure stray pointers in the
> application using my db (which will load into application process
> memory) does not damage my page(s) from the time of latest checkpoint
> and next checkpoint? And if it does, I don't want to flush it to disk,
> how do I detect a page corruption to avoid this?
>
> 1)
> Am I simply being paranoid?
>

What you want is for the application to bomb out with a general protection fault when it tries to access memory owned by the DB. Separate the in-memory DB into its own process.

> 2)
> Should I, for every update, calculate the checksum of the changed
> record? Records can be large and this sounds like a pain in the back,
> performance-wise.
>
> Any other, better ways out there, to achieve what I want?
>
> The checksum does not have to be idiot proof, that is, the checksum
> does not have to be unique for the bit pattern of the page, unless
> there is a cheap way of achieving this of course, but I don't think
> there is...
>
> BRs
> /Sune
>
Received on Sun Jul 01 2007 - 15:30:05 CEST

Original text of this message