The one thing to understand first
Streaming replication keeps a standby byte-for-byte identical to its primary by shipping the primary’s WAL stream and replaying it continuously. Because it replays the same physical changes, the standby is an exact copy — same data files, same block contents — which is why it requires the same major version and architecture.
Physical replication is not “copying rows” — it is replaying the primary’s recovery log on a second machine, forever. The standby is running the same crash-recovery code that runs after a restart, just never reaching the end.
The two key processes
- walsender (on the primary,
src/backend/replication/walsender.c) — a backend dedicated to one standby. It reads WAL and streams it over a replication connection.
- walreceiver (on the standby,
walreceiver.c) — connects to the primary’s walsender, receives the WAL stream, and writes it to the standby’s WAL.
- startup process (on the standby) — continuously replays the received WAL into the data files using the same recovery code used after a crash.
The flow of a change
- A transaction on the primary writes WAL records and flushes them at commit.
- walsender notices new WAL and streams it to each connected walreceiver.
- The standby’s walreceiver writes the WAL locally and signals the startup process.
- The startup process replays the records, applying them to data pages.
- If the standby allows queries (hot standby), readers see the replayed state.
Setting it up
-- On the primary: a replication role and slot
CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD '...';
SELECT pg_create_physical_replication_slot('standby1');
-- Build the standby from a base backup
pg_basebackup -h primary -U replicator -D /data -R --slot=standby1
-- -R writes the connection info; the standby starts in recovery and streams.
Synchronous vs asynchronous
By default replication is asynchronous: the primary commits as soon as its own WAL is flushed, not waiting for the standby. This is fast but means a few recent transactions can be lost if the primary dies before the standby receives them. Synchronous replication (covered separately) makes the primary wait for standby confirmation, trading latency for zero data loss.