multixactlisted

# multixact — multi-transaction IDs for tuple locking Every heap tuple has an `xmax` field. In the simple case, `xmax` is the XID of a transaction that either deleted or exclusively locked the tuple. But PG supports **multiple concurrent lockers** on the same tuple (row-level shared locks + key-share locks + non-blocking-with-updates), which requires representing "this tuple is currently locked by transactions A, B, and C" in a fixed-size field. The solution: when a tuple has multiple lockers, `xmax` holds a **MultiXactId** and the `HEAP_XMAX_IS_MULTI` infomask bit is set. The MultiXact ID is a handle into a separate lookup table (`pg_multixact/`) that maps to the set of member XIDs + their per-member lock strength. ## The file map | File | Lines | Role | |---|---:|---| | `access/transam/multixact.c` | 95K | **The single file for all things MultiXact.** SLRU management, ID allocation, member lookup, freezing, wraparound. | | `access/transam/subtrans.c` | 13K | Not multixact but often confused — subtransaction xid → parent xid mapping. Same SLRU pattern, different purpose. | | `access/transam/clog.c` | 37K | Also not multixact but often confused — regular transaction commit status. Same SLRU pattern, different purpose. | MultiXact lives on-disk in **two SLRU segments**: - `pg_multixact/offsets/` — one entry per MultiXactId, giving the offset into `members/` for that multixact's member list. - `pg_multixact/members/` — variable-length arrays; each entry is `(xid, Transact