Path: text.usenetserver.com!out03b.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!postnews.google.com!i38g2000prf.googlegroups.com!not-for-mail From: Sune Newsgroups: comp.databases.theory Subject: How to make sure I don't write a corrupt page to db when I checkpoint? Date: Sun, 01 Jul 2007 01:15:24 -0700 Organization: http://groups.google.com Lines: 29 Message-ID: <1183277724.576790.246740@i38g2000prf.googlegroups.com> NNTP-Posting-Host: 122.208.231.109 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1183277725 21675 127.0.0.1 (1 Jul 2007 08:15:25 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 1 Jul 2007 08:15:25 +0000 (UTC) Cc: comp.software User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: i38g2000prf.googlegroups.com; posting-host=122.208.231.109; posting-account=JUuO3g0AAABZ-LSqspSVSH7OrgKv3N0c Xref: usenetserver.com comp.databases.theory:165488 X-Received-Date: Sun, 01 Jul 2007 04:15:25 EDT (text.usenetserver.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? 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