Glossary
The vocabulary behind every incident
Understand the language first and the error pages read faster. Each term is defined in plain English, tied to why it matters operationally, and pointed at the file where it lives in the PostgreSQL source.
MVCC
Multi-Version Concurrency Control lets readers and writers proceed concurrently by keeping row versions instead of blocking every read.
It explains why PostgreSQL can serve consistent reads under write pressure and why vacuum is a first-class operational concern.
Where it lives in the source
src/backend/access/heap/heapam.c
Visibility map
A compact structure that records whether a heap page is all-visible or all-frozen, which helps PostgreSQL skip unnecessary heap checks.
It directly affects index-only scans, autovacuum efficiency, and the latency profile of read-heavy tables.
Where it lives in the source
src/backend/access/heap/visibilitymap.c
Write-Ahead Log (WAL)
An append-only record of every change written before the change reaches the data files, so committed work survives a crash and can be replayed during recovery.
WAL underpins durability, crash recovery, replication, and point-in-time restore — most availability decisions trace back to it.
Where it lives in the source
src/backend/access/transam/xlog.c
Autovacuum
The background process that reclaims space from dead tuples and refreshes planner statistics without a human running VACUUM by hand.
When autovacuum falls behind, tables bloat, indexes slow down, and transaction-ID wraparound risk climbs — it is a first-order operational concern.
Where it lives in the source
src/backend/postmaster/autovacuum.c
Dead tuple
A row version that is no longer visible to any transaction but still occupies space on the heap page until vacuum removes it.
Dead tuples are the raw material of bloat; understanding them explains why UPDATE-heavy tables need aggressive vacuuming.
Where it lives in the source
src/backend/access/heap/pruneheap.c
Transaction ID wraparound
PostgreSQL numbers transactions with a 32-bit counter; if very old rows are never frozen, the counter can appear to wrap and hide committed data. Vacuum freezing prevents it.
Wraparound is one of the few conditions that can force PostgreSQL into a protective read-only state — a genuine outage risk on neglected databases.
Where it lives in the source
src/backend/access/transam/varsup.c
TOAST
The Oversized-Attribute Storage Technique that transparently compresses and/or moves large column values into a side table so main rows stay within a page.
TOAST explains why wide text/JSON columns behave differently for storage, compression, and I/O than small scalar columns.
Where it lives in the source
src/backend/access/common/toast_internals.c
Checkpoint
A point at which PostgreSQL flushes dirty buffers to disk and records a WAL position, bounding how much WAL must be replayed after a crash.
Checkpoint timing trades recovery time against write spikes; tuning it is central to smoothing I/O on write-heavy systems.
Where it lives in the source
src/backend/postmaster/checkpointer.c
Lock manager (heavyweight locks)
The subsystem that grants and queues table- and object-level locks, tracking what each transaction holds and what it waits for.
Every blocking incident, lock timeout, and deadlock is ultimately a story told by the lock manager's wait queues.
Where it lives in the source
src/backend/storage/lmgr/lock.c
Row-level lock
A lock taken on individual tuples (for example by UPDATE or SELECT ... FOR UPDATE) so concurrent writers coordinate without blocking readers.
Row locks are where most application-level contention lives; how you order and hold them decides whether you deadlock.
Where it lives in the source
src/backend/access/heap/heapam.c
Serializable Snapshot Isolation (SSI)
PostgreSQL's implementation of SERIALIZABLE that detects dangerous read/write dependency cycles between concurrent transactions and aborts one to preserve serial equivalence.
SSI is why SERIALIZABLE workloads must be prepared to retry transactions that fail with a serialization error.
Where it lives in the source
src/backend/storage/lmgr/predicate.c
Deadlock detector
A routine that runs after deadlock_timeout on a waiting backend, builds the wait-for graph, and cancels one transaction when it finds a lock cycle.
It explains the exact behavior behind SQLSTATE 40P01: PostgreSQL does not prevent deadlocks, it detects and breaks them.
Where it lives in the source
src/backend/storage/lmgr/deadlock.c
HOT update (heap-only tuple)
An optimization where an UPDATE that does not change any indexed column can store the new row version on the same page without adding index entries.
HOT updates dramatically reduce index bloat and write amplification, which is why avoiding needless index columns pays off.
Where it lives in the source
src/backend/access/heap/heapam.c
Query planner
The cost-based optimizer that turns a parsed query into an execution plan by estimating the cost of alternative scans, joins, and orderings.
Reading and influencing planner decisions (via statistics, indexes, and settings) is the core skill of query performance work.
Where it lives in the source
src/backend/optimizer/plan/planner.c
Table statistics (ANALYZE)
Sampled distributions of column values stored in pg_statistic that the planner uses to estimate row counts and choose plans.
Stale or missing statistics are a leading cause of sudden bad plans; ANALYZE is often the cheapest performance fix.
Where it lives in the source
src/backend/commands/analyze.c
Backend / connection limit
Each client connection is served by its own backend process; max_connections caps how many can exist at once, after which new connections are refused.
It explains why connection pooling matters and why unbounded client concurrency turns into SQLSTATE 53300 under load.
Where it lives in the source
src/backend/postmaster/postmaster.c