db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oystein.Grov...@Sun.COM (Øystein Grøvlen)
Subject Re: [jira] Commented: (DERBY-298) rollforward will not work correctly if the system happens to crash immediately after rollforward backup.
Date Fri, 27 May 2005 09:43:01 GMT
>>>>> "MM" == Mike Matrigali <mikem_app@sbcglobal.net> writes:

    MM> If possible I would like to see a solution that does not
    MM> depend on a special log record being first in the new log.  At
    MM> the level of specific log files, it does not know much about
    MM> log records.  It would be nice if anything that dealt with log
    MM> records just saw them as a single sequence of log records
    MM> which just happen to be split across multiple files in this
    MM> implementation.  Putting stuff in the per log file hdr is fine
    MM> as this is specific to this implementation.

I understand and agree.  We should separate the implementation of log
files from the implementation of a stream of log records.

    MM> Couldn't step 11 be another bit in the file hdr?

Yes, I think it could.  However, I am starting to think that special
handling of crashed during log switching is not really necessary.

Suresh wrote in the bug report:

    > On next crash-recovery system ignores the  empty log 
    > file and starts writing to the previous log(say log1.dat),  
    > even thought there was successfule log file switch  before the crash.
    > The reason I belive it is done this way to avoid special 
    > handling of crashes  during the log switch process. 

Looking at the steps of log switching again:

    >> 1. Check if file with next file number exists.  If so, delete it
    >> 2. Open new log file
    >> 3. Initialize file (write header) and sync
    >> 4. Write end marker to old file 
    >> 5. Flush old file to disk
    >> 6. Close old file
    >> 7. Preallocate space in new log file and sync
    >> 8. Close new file
    >> 9. Reopen new file in RWS mode
    >> 10. Go to current end position (after header).

Why are we concered about crashes after step 3?  According to Suresh
step 7 (preallocation) is not strictly necessary.  Hence, the usage of
the new log file is not dependent on steps 4 - 10.  The recovery
process will have to deal with an incomplete old file anyway.  What is
the problem with using the new file after recovery as long as the
header is valid?


View raw message