# WAL rule requires only the undo information in the log have been output to stable storage, and permits the redo information to be written later

I was going through the "write-ahead logging (WAL) rule" from the Database System Concepts text by Korth et. al, where I came across the following excerpt:

Strictly speaking, the WAL rule requires only that the undo information in the log have been output to stable storage, and permits the redo information to be written later. The difference is relevant in systems where undo information and redo information are stored in separate log records.

What I have learned after reading the text is that: both the undo and the redo information is important in restoring the database to a consistent state after some failure. What I feel is that the undo and the redo operations are equally important and I feel both should be OUTPUT to the stable store before actual modifications of the data of the database are made to disk.

What the authors say about undo in the context of WAL is fine with me. I feel uneasy with what they say about the redo. ["permits the redo information to be written later"] In a situation suppose, the database transaction modifications after half done and the redo info. are still not written to the stable storage, then once the system becomes functional again, it shall have no idea about the "half done" modifications done by the transaction.

What do the authors actually mean to say?

The use of the different Logs depends on the Recovery Algorithms used. In general those algorithms are classified in four different classes:

• Undo-Redo, requires both undo and redo
• Undo-NoRedo, requires undo, but not redo
• NoUndo-Redo, requires redo, but not undo
• NoUndo-NoRedo, requires neither undo nor redo

The Write Ahead Log (WAL) is strictly necessary when applying the Undo Rule:

If a database page is updated before the transaction has committed, its before-image must have been previously written to the log file in the stable memory.

This means that the if we use, for instance, a recovery algorithm based on the Undo-NoRedo approach, we must have the before-image written on the stable memory, but we can defer the writing of the after-image.

• Thanks, but I could not quite get the meaning of the phrase " permits the redo information to be written later" that the authors say. Please could just elaborate your answer a little. I am new to DBMS, but I think I know the points (/theory) which you say, but just having a problem in tying the thread together and looking at the big picture... Jun 1 '21 at 21:16