Replication, upgrades, and handover | PostgreSQL: operations and recovery

Concept and mechanism

Receiving WAL does not mean replaying it: track receipt, replay, and application freshness requirements. Slots prevent premature recycling of required records, but a stopped consumer can pressure primary storage. Limiting retention protects capacity with the risk of requiring consumer rebuilding. Before promoting a standby, losing contact does not prove primary stopped accepting writes. The design needs fencing and unique authority to avoid divergence. Define who may decide promotion, what loss is acceptable, and how to confirm the new application path. Streaming or running state does not replace this evidence.

Guided application

In a fictional migration project, logical replication can align rows without synchronizing DDL or sequence state. Cutover includes those components, grants, jobs, and a controlled write boundary. Major upgrades require their own strategy; minor updates have a different process including release-note review. pg_upgrade --check helps identify incompatibilities without performing migration. In link mode, starting the new cluster prevents simply using the old directory as an independent rollback. Choosing copy, link, or clone requires space, filesystem support, and a recovery plan. Handover delivers evidence, a runbook, owners, and residual risks, including what remains unrehearsed.

IN PRACTICE

Matching target counts do not prove that the next sequence-generated key will be valid.

Common pitfalls

Receipt as replay; slot as unlimited backup; DNS as fencing; hard link as an independent copy.

Related topics: Connections, identities, and privileges · Transactions, blocking, and resumption · Plans, indexes, and memory

Take this idea with you

A change ends when data, application, and operation are validated.

Create account

Reference: Streaming replication and slots · PostgreSQL 18 reference semantics;18.6 current stable at review