How PolarDB Guarantees Transaction Atomicity: From WAL to Visibility

1. Introduction

In the towering architecture of databases, the query optimizer and transaction system are two load‑bearing walls; they shape many data structures, mechanisms, and features. This article focuses on the transaction system, specifically the atomicity aspect of PolarDB.

2. Questions

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

Why is data that has been written successfully guaranteed not to be lost?

How can a database recover after a crash and still reflect committed data?

What exactly is “logically committed” data, and at which step does a transaction truly commit?

3. Background

3.1 Position of Atomicity in ACID

ACID was introduced in the SQL‑92 standard. Atomicity is the first of the four properties; this article concentrates on its role within transactions.

My personal view splits ACID into two perspectives: AID (Atomicity, Durability, Isolation) from the transaction side, and C (Consistency) from the user side.

Atomicity : a transaction is all‑or‑nothing; the system must guarantee exactly two states—success or failure—and keep logical and physical results consistent.

Durability : once a transaction commits, its effects persist permanently; it defines the point after which crashes must recover the committed state.

Isolation : prevents concurrent transactions from seeing intermediate states.

Consistency : the database must satisfy user‑defined invariants after any series of transactions.

4. Internal Requirements of Atomicity

To consider a transaction atomic, three conditions must hold:

There exists a precise commit timestamp.

Transactions that start before this timestamp see state T; those that start after see state T+1.

Crashes before the timestamp must recover to T; crashes after must recover to T+1.

The commit timestamp is called the “atomicity point”; the later point is the “persistence point”.

5. Atomicity Implementation Options

5.1 Simple Direct‑IO

Writing data directly to disk without a log can leave the database in a half‑written state (T+0.5) after a crash, violating atomicity.

5.2 Simple Buffer‑IO

Using a shared buffer pool allows writes to be staged in memory; if a crash occurs before commit, the dirty pages can be discarded, preserving atomicity. However, persisting multiple dirty pages atomically is still problematic.

5.3 Write‑Ahead Log (WAL) + Buffer‑IO

Adding a WAL records changes before the data pages are flushed. Each page stores the LSN of its latest log entry, ensuring log‑data consistency. On crash, replaying the WAL restores the correct state.

Control of dirty page flushing is achieved by a checkpoint process that writes a REDO LSN to the log, guaranteeing that all dirty pages have been persisted.

6. Full‑Page Mechanism

To handle cases where a partially written page becomes corrupted, PolarDB writes a full‑page backup block (the entire page) to the WAL after the first modification post‑checkpoint. This guarantees that any page can be reconstructed during recovery.

7. Visibility Mechanism

Visibility is determined by MVCC snapshots. Each tuple stores xmin , xmax , cid , and ctid fields. Snapshots capture the transaction state at a point in time. The visibility decision order is snapshot → clog → infomask.

8. PolarDB Atomicity Process

The commit path includes:

Write a commit record to the WAL buffer.

Flush all WAL records of the transaction to disk.

Write the transaction’s status to the CLOG buffer.

Update the ProcArray, making the transaction visible to other sessions (the atomicity point).

Rollback follows a similar path but first checks CLOG; if the transaction is already marked committed, a crash is triggered.

9. Summary and Outlook

The article dissected how PolarDB achieves transaction atomicity through WAL, buffer pools, full‑page backups, CLOG, and ProcArray. These mechanisms together provide crash‑safe recovery, consistent visibility, and durable commits, forming the foundation of reliable database systems.