In this lesson, you will learn how PostgreSQL uses the Commit Log (CLOG) to keep track of whether a transaction is still running, has been successfully committed, or was aborted.
Why do we need a CLOG?
When PostgreSQL uses MVCC (Multi-Version Concurrency Control), multiple versions of a row exist simultaneously. To determine which version is "visible" to your query, the database needs to know the status of the Transaction ID (XID) that created that row.
While the Write-Ahead Log (WAL) records the sequence of changes for recovery, it isn't efficient for looking up the status of a specific XID during a high-speed read. Instead, PostgreSQL maintains a dedicated, small, fixed-size structure called the CLOG (Commit Log).
How it works
The CLOG is a bit-mapped file that acts as a simple status array. For every transaction ID, PostgreSQL stores two bits of information:
IN_PROGRESS: The transaction is still running.COMMITTED: The transaction finished successfully.ABORTED: The transaction failed or was rolled back.
When a query reads a row, it sees an XID attached to that tuple. It consults the CLOG to translate that XID into a status. If the status is COMMITTED, the engine knows it is safe to display the data to the user. If it is IN_PROGRESS or ABORTED, the engine ignores that row version.
A Conceptual View
Think of the CLOG like a giant status board for every transaction ever started:
XID 1001: COMMITTED
XID 1002: IN_PROGRESS
XID 1003: ABORTED
When you perform a SELECT, the database doesn't need to re-read the entire transaction log. It simply checks the status board (CLOG) for the version of the data it just found. This ensures that you only see data that is consistent with the global state of the database, upholding the requirements of your transaction isolation level without the overhead of scanning complex logs.
Because the CLOG is stored in a predictable memory-mapped file structure, this look-up happens in constant time, allowing PostgreSQL to remain highly performant even under heavy concurrent workloads.
Key Takeaway: The CLOG is the definitive source of truth for transaction status, allowing the database to instantly verify if a row version is visible by mapping each XID to a committed, aborted, or in-progress state.