How PolarDB Guarantees Transaction Atomicity: From WAL to Visibility

Introduction

In the massive architecture of databases, the query optimizer and transaction system are two crucial pillars; this article focuses on the atomicity aspect of PolarDB's transaction system.

Key Questions

How does a database guarantee atomicity and what special data structures are used?

Why can successfully written data be guaranteed not to be lost?

How can a database recover after a crash and restore logically committed data?

What exactly is a logically committed datum and at which step does a transaction truly commit?

Background

Atomicity is the first property of ACID. It means a transaction either fully succeeds or fully fails. It is distinguished from durability (the data remains after commit) and isolation (concurrency control).

Internal Requirements of Atomicity

Three conditions must hold: a definitive commit point, visibility of the new state only after that point, and crash recovery to the appropriate state before or after the point.

Atomicity Schemes

Simple Direct‑IO writes data directly to disk without logs, leading to half‑written pages on crash and breaking atomicity.

Simple Buffer‑IO introduces a shared buffer pool, allowing asynchronous writes and discarding uncommitted changes, but still cannot guarantee atomicity when a crash occurs during page flush.

Therefore a write‑ahead log (WAL) is introduced.

WAL + Buffer‑IO Scheme

Before modifying a page, a log record (xlog) with a LSN is written to the WAL buffer; the page stores the latest LSN. On crash, replaying the WAL restores the correct state. Checkpoint processes write a checkpoint record containing the REDO LSN, and dirty pages are flushed asynchronously.

Full‑Page Mechanism

To handle partially written pages, PolarDB writes a full‑page backup block to the WAL after the first modification following a checkpoint, ensuring any corrupted page can be reconstructed.

Visibility Mechanism

Tuple headers contain xmin, xmax, cid, and ctid. Snapshots capture the state of all transactions at a moment. Visibility is determined by the order: snapshot → clog → infomask. ProcArray holds the snapshot information used during visibility checks.

Atomicity and Durability Points

Two critical points are identified: the durability point (after the commit log is flushed) and the atomicity point (after the transaction is recorded in ProcArray). The former guarantees crash‑recovery; the latter guarantees that other transactions see the new version and the transaction can no longer be rolled back.

PolarDB Implementation

The commit path writes the WAL commit record, forces WAL flush, updates CLOG, and finally writes the transaction entry to ProcArray, which marks the atomicity point. Rollback checks CLOG, writes abort logs, and updates ProcArray accordingly.

Conclusion

PolarDB achieves transaction atomicity by combining WAL, buffer management, checkpointing, full‑page logs, and a clear separation of durability and atomicity points, ensuring both reliable crash recovery and consistent data visibility.