
Interactive Interpreter Undo (2016) - pcr910303
http://ballingt.com/interactive-interpreter-undo/
======
malisper
Fun fact - a lot of this is kind of stuff is used in SQL databases! Before you
finish a transaction (i.e. a sequence of commands), you can rollback the
transaction. This will undo the effects of every command ran as part of the
transaction. It's interesting to take a look at how different production
databases implement undo:

MySQL and Oracle use the "reconstructing previous states from the current
state" strategy. As commands are ran, they keep track of how to undo those
commands in the "undo log". If you rollback a transaction, all they do is run
the commands in the undo log.

Postgres uses a different strategy. When Postgres modifies a row, it marks the
old row as deleted and inserts a new row. Furthermore these changes are
associated with the current transaction and considered to be pending until the
current transaction completes. If the current transaction fails, Postgres will
use the original version of the row because the transaction that modified it
never actually completed.

SQL databases have a completely separate form of undo used for point in time
backups. This is the ability to restore a copy of your database from any point
in time in the past. As far as I know, use a combination of the "recording
each state" and "reconstructing previous state from initial state". There's
two parts to your typical database backup. There's the base backup which
captures the state of your DB at a specific point in time. Separately there's
a redo log that captures every change made to the data after the base backup
was created. By replaying the changes made before a certain time, you can
restore the DB to any state after the base backup was created.

