Row versions and snapshots: the on-disk mechanics

You know that MVCC gives each transaction a snapshot. The question is: what is a snapshot, exactly, and how does Postgres decide — for every single row on every single page scan — whether that row belongs in your snapshot or not?

Every row carries a header

When Postgres stores a tuple on a heap page, it prefixes the user columns with a 23-byte system header containing:

• t_xmin — the transaction id that inserted this version
• t_xmax — the transaction id that deleted or updated this version (zero if still live)
• t_cid — the command id within a transaction
• t_ctid — a pointer to the next version of this row (used for chaining updates)
• t_infomask / t_infomask2 — bitmaps flagging commit status, lock state, freeze state, and HOT bits

These fields are how visibility decisions get made on every single tuple Postgres looks at.

How a snapshot decides what to read

When a transaction begins, Postgres builds a snapshot — a small structure with three numbers:

• xmin — the oldest still-running transaction id
• xmax — one past the newest committed id at snapshot time
• xip — the list of in-progress transactions between xmin and xmax

The visibility rule applied to every tuple is roughly: a tuple is visible if its t_xmin is committed and not in the in-progress list (xip), and its t_xmax is either zero, rolled back, or in the in-progress list. That is it. No locks involved.

• Under READ COMMITTED (the Postgres default), a fresh snapshot is taken at the start of each statement.
• Under REPEATABLE READ, the snapshot is taken once at the first statement of the transaction.

INSERT, UPDATE, DELETE — what actually happens on disk

INSERT places a fresh tuple with t_xmin = current_txid and t_xmax = 0.

UPDATE is two operations: marks the old tuple’s t_xmax = current_txid and inserts a new tuple with the new values (t_xmin = current_txid, t_xmax = 0). The old tuple’s t_ctid is chained to the new tuple’s page-and-offset.

DELETE just marks the existing tuple’s t_xmax = current_txid. Nothing is physically removed. All operations are logically reversible until commit and physically present until VACUUM.

A visibility walkthrough

Connection A runs BEGIN; UPDATE accounts SET balance = balance - 100 WHERE id = 42; — does not commit. Connection B runs BEGIN; SELECT balance FROM accounts WHERE id = 42; at the same time.

Row id=42 now has two heap versions:

• v1: balance=100, t_xmin = prior committed tx, t_xmax = A
• v2: balance=0, t_xmin = A, t_xmax = 0

B’s snapshot was taken at B’s BEGIN. A is in B’s xip.

• v1: t_xmin is committed (passes lower bound), t_xmax = A (in xip, deletion not visible) → v1 is visible
• v2: t_xmin = A (in xip, fails lower bound) → v2 is invisible

B reads balance=100. No locks, no waiting.