Failover moves PostgreSQL service from an unavailable primary to a standby or alternate system. The tempting shortcut is a custom promotion script that selects any reachable replica. section 9.6
Why replica choice matters
Suppose the primary fails while one standby is behind in WAL replay. Promoting that lagging standby omits transactions already received by other replicas, potentially violating the expected RPO. Promotion also creates a new timeline; the other replicas cannot simply follow it and may need their WAL rewound before they can rejoin. A network partition creates another danger: a replica may be promoted while the original primary is still accepting writes. section 9.6
Safer operational guidance:
- Use redundant standby nodes through replication rather than relying on a single database server. section 9.7
- Avoid manual failover and homegrown scripts that may overlook lag, split-brain conditions, recovery steps, or timeline changes. section 9.6 section 9.7
- Prefer proven PostgreSQL high-availability tools such as RepMgr, Patroni, or CloudNativePG for Kubernetes. section 9.7
