On Tue, Feb 3, 2009 at 2:19 PM, Kiran Ayyagari <ayyagarikiran@gmail.com> wrote:

Hi Alex,

I'm seriously thinking the use of the CL for a journal is not a good decision. The journal needs to be fast and simple, doing only one thing and doing it fast and flawlessly.
+1, by 'replica of CL' I mean the journal contains the same data what CL stores in its store minus the indices and journal just writes that data in a sequential order (CL could be a B-Tree).

Right I agree the CL is fine as it is with the B-Tree and indices.  The journal need not be a btree if all we need is sequential access.  We merely need a simple pointer or two into it to know where the last operation was successfully processed.  Hence everything earlier or after it in the file represents currently active operations.

However an assumption I made here was that each valid operation succeeds at least before storing its data in CL
( we have to write the same data to journal before storing in CL) this way we no longer need any marking operation cause
if the master db gets corrupted we use CL to restore and if the CL also gets corrupted then we can restore the CL from
journal(start from the beginning hence no intermediate 'marks') and then restore the master db.

I agree that *ONLY* change operations that have succeeded should be logged into the CL.  But I think we at least need a marker in the journal to track the horizon between completed and in progress operations no?