Re: implementing a database log

From: Christoph Rupp <>
Date: Mon, 21 Apr 2008 14:58:54 -0700 (PDT)
Message-ID: <>


On Apr 21, 11:00 pm, "Brian Selzer" <> wrote:
> Why not go with #4:
> 4. a physical log based on modified rows. Whenever a row is modified, added
> or removed, it is logged. Then you could also implement row
> versioning--just add a row version field to the physical rows. I believe
> that this what snapshot isolation is built on.

It's not an SQL database, i don't even have the notion of "rows", but basically i think your #4 is the same as my #1 or #2.

My problem is that one single insert can be split in up to 3 or even more file operations, depending on the size of the B+Tree index (it has to be split, if a page overflows, etc). I don't have an atomic "insert(key, value)" operation.

And in that case, i have to log 3 (or more) different file events. And that brings me back to my question - do i log the whole modified page (usually a page is between 16kb and 64kb), or just the modified region in the page... Received on Mon Apr 21 2008 - 23:58:54 CEST

Original text of this message