I answered on LinkedIn about how transaction log, redo log, and WAL are the same.
In practice MSSQL transaction log ~= Oracle redo log ~ PostgreSQL WAL
but with more details: 🧵👇🏻
In practice MSSQL transaction log ~= Oracle redo log ~ PostgreSQL WAL
but with more details: 🧵👇🏻
1. A transaction log must include:
- undo log
- redo log
- transaction boundaries
for A,C,I properties of ACID
It can be in memory but must be synced to disk at commit (#LogForceAtCommit) for the D property of ACID
- undo log
- redo log
- transaction boundaries
for A,C,I properties of ACID
It can be in memory but must be synced to disk at commit (#LogForceAtCommit) for the D property of ACID
2. For performance, writing data buffers to disk is deferred and reordered because random writes are slow. The changes lost after a crash can be rolled forward from the redo log to recover the on-disk state
3. The state on disk can have incomplete or uncommitted transactions. This is why the transaction log (with undo) must be written to disk before, with #WriteAheadLogging, to be able to rollback uncommitted transactions after a crash
There are some implementation variations. For example, Oracle redo log indirectly includes undo log (as the redo of the rollback segment). Similarly, PostgreSQL undo log is the redo log of xmin/xmax changes.
Oracle can bypass the buffer cache for some operations (direct-path load) and then does #WriteBehindLogging for it.
@Yugabyte writes provisional records so that there are no incomplete transactions in regularDB so WAL is lighter and rollbacks faster
@Yugabyte writes provisional records so that there are no incomplete transactions in regularDB so WAL is lighter and rollbacks faster
• • •
Missing some Tweet in this thread? You can try to
force a refresh
