The one thing to understand first
A running PostgreSQL server is not one program — it is a small family of cooperating OS processes sharing one block of memory. One supervisor, the postmaster, starts everything, forks a dedicated process for each client connection, and launches a handful of specialist background workers that handle checkpoints, dirty-buffer writeback, WAL flushing, vacuuming, and archiving. Knowing who does what turns an opaque ps listing into a map of exactly where your I/O and CPU are going.
The postmaster: supervisor and parent
Everything starts in src/backend/postmaster/postmaster.c. PostmasterMain creates the shared memory segment, opens the listening socket, and enters ServerLoop. For each incoming connection it fork()s a backend (one OS process per connection). It also forks the auxiliary processes and, crucially, watches them: its reaper() handler catches any child that exits. If a backend dies unsafely (a crash that may have corrupted shared memory), the postmaster takes the whole cluster down to a safe state — it kills every child, resets shared memory, and runs recovery — which is why one segfaulting backend briefly drops all connections.
The specialist workers
Each background process is a focused loop: