On 6/22/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> > Not in all systems. A few now perform in-memory UNDO and only write
> > it to disk if and when it is required.
>
> How does that work? If the last transaction is not finished after it
> wrote the tuple when the power goes out, and the UNDO is not written to
> disk either, how do you reconstruct the tuple at all?
It still follows normal transaction semantics... on commit, the REDO
record is written to disk. If the block was not written to disk and
the database crashes, the on-disk representation of the block remained
unchanged and recovery would pick up the REDO record from the log and
reapply it.
However, say someone updates a record which moves the old tuple value
to an in-memory UNDO location and changes the in-memory block
representation... if a checkpoint occurs before the user commits, the
block must be written to disk in changed form which means that the
UNDO record must also be written to the log (before the block is
written to disk). In the event of a crash, recovery would see that
the transaction never committed and would apply the UNDO to the block.
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/
