Dick Dowdell
1 min readJul 11, 2021

--

Peter, thank you for an excellent article on an important topic. I would recommend it to anyone who would like to cross-check their RDBMS mental model with reality.

I must, however, take exception to your statement that databases store transactions, not state. A database stores the result of all committed transactions, i.e, the state of the data. The WAL is a powerful mechanism for guaranteeing that an accurate, consistent database state can be recovered after a DBMS failure.

As shown in your example, the WAL contains a sequential list of all DML changes that have been committed. All physical DBMS writes are from the Write Ahead Log. After a physical write is completed, the DBMS' pointer to the WAL is advanced. In simple terms, when a DBMS like PostgreSQL is started, it begins by writing to disk from the WAL at the last pointer, recovering from any failure to shut down normally. A DBMS does not reprocess any data positioned before that pointer. Typically, WAL blocks that have have been successfully written to a database can be discarded. WAL files are frequently archived, because they can be used to roll forward a database backup after a catastrophic failure.

As a senior architect for a DBMS company, I used the WAL as the source of changed data to replicate to other database mirrors. WAL entries are at a table row level, not a transaction level, though the WAL does contain only committed changes. PostgreSQL documentation covers the WAL in great detail.

--

--

Dick Dowdell
Dick Dowdell

Written by Dick Dowdell

A former US Army officer with a wonderful wife and family, I’m a software architect and engineer who has been building software systems for 50 years.

No responses yet