# 4.4 Transactions (The Atomic Seal)
In the database, errors are inevitable. A network failure, a power surge, or a logic error can interrupt a process halfway through. Without a guarantee of integrity, these failures would leave your data in a mangled, inconsistent state—a digital void where money vanishes and orders exist without customers.
To prevent this, Postgres uses **Transactions**—a formal **Atomic Seal** that a set of actions is one single, indivisible "Unit of Work." This is the foundation of **Atomicity**: either every action in the set succeeds, or none of them do.
## The Atomic Flip: The Commit Log (CLOG)
While the **WAL** records the physical details of *what* changed, the **Commit Log (CLOG)** records the logical status of every transaction. Physically located in the `pg_xact` directory, the CLOG allocates exactly **2 bits** for every Transaction ID (XID):
* **`00`**: In-Progress
* **`01`**: Committed
* **`10`**: Aborted
* **`11`**: Sub-committed
This is how Postgres achieves instantaneous atomicity. Even if a transaction updated millions of **Tuples** across thousands of **Pages**, the engine doesn't finalize them one by one. Instead, it simply flips the 2 bits in the CLOG from `00` to `01`. At that exact millisecond, every change made by that XID becomes logically visible to the entire world.
## The WAL Seal: Making it Real
The flip in the CLOG is the logical finality, but the **WAL Commit Record** (`XLOG_XACT_COMMIT`) is the physical authority. Before Postgres updates the CLOG, it must first write this commit record to the **[[Chapter 4/4.1 - The Pocket Diary (WAL & fsync)|Write-Ahead Log]]** and ensure it is physically `fsync`'d to disk.
Once that single record is on disk, the transaction is durable. If the power fails before the CLOG is updated, Postgres will find the commit record in the WAL during recovery and finish the job.
## Early Persistence: Moving Data to the Cellar
A common misconception is that uncommitted data never reaches the disk. In reality, Postgres must manage its memory (the **Shared Buffer Pool**) carefully.
Because memory is finite, the **Background Writer** is allowed to move a "dirty" page containing uncommitted data down to the **Disk** (the cellar) to make room for new guest orders.
* **Why it's safe**: Because of the "Write-Ahead" rule, the engine ensures that the WAL records—containing the "Undo" information—are physically on disk *before* the dirty page itself is flushed. If the transaction eventually rolls back, Postgres has everything it needs in the WAL to "undo" the changes that were moved to the cellar early. This separation allows the engine to handle transactions that are significantly larger than the available RAM.
## The Physical Stamp: Hint Bits
Checking the CLOG for every single tuple in a 10-million-row scan would be a performance disaster. To avoid this, Postgres uses **Hint Bits** (`HEAPTUPLE_HINT_BITS`).
The first time any process visits a tuple after its parent transaction has finished, it looks up the status in the CLOG and immediately **stamps** the tuple's header with a hint bit: `COMMITTED` or `ABORTED`.
Subsequent visitors don't need to check the CLOG; they simply look at the stamp on the suitcase. This "caching" of the transaction status is what allows Postgres to maintain high performance even with massive histories.
> [!NOTE]
> **The Lock Footprint**: This is why even a `SELECT` query can occasionally trigger a write to disk. If the engine needs to "stamp" a hint bit on a page that was previously clean, it marks the page as **Dirty**, requiring an eventual flush to Disk.
---
| ← Previous | ↑ Table of Contents | Next → |
| :--- | :---: | ---: |
| [[Chapter 4/4.3 - The Town Crier (Logical Replication)\|4.3 The Town Crier (Logical Replication)]] | [[Learn You a Postgres for Great Good\|Home]] | [[Chapter 4/4.5 - The Looking Glass Windows (Isolation)\|4.5 The Looking Glass Windows (Isolation Levels)]] |