Fence the former PostgreSQL primary before accepting failover

Make authority transfer and protection against a returning former primary part of failover acceptance.

Source facts

PostgreSQL 17 documentation requires a mechanism that prevents a restarted former primary from continuing to act as primary after failover. Otherwise, both servers can believe they are authoritative and data loss can follow. PostgreSQL itself does not provide the system software that detects a failed primary and notifies the standby. After promotion, redundancy also needs rebuilding: the new primary operates alone until a suitable standby has been recreated or rejoined.

Source: PostgreSQL 17 — Failover.

Applicability

This applies to PostgreSQL 17 physical-standby failover design. It does not endorse a particular cluster manager, fencing device, network topology, or automatic failure-detection policy.

DSE recommendation

DSE recommends treating authority transfer, client redirection, former-primary exclusion, and restoration of redundancy as separate named steps. Define who can approve promotion when failure is ambiguous. Keep a written route back to a protected two-server state, rather than ending the incident when the application reconnects. Include the behavior of a recovered old host in the design review, with a clear rule preventing it from accepting writes until its new role has been established.

Verification

In a controlled rehearsal, promote the standby and simulate the former primary returning. Verify that the excluded node cannot accept application writes, clients reach the intended primary, and a standby is restored afterward. Retain the observed authority transitions and any manual approvals in the rehearsal record.

Official reference

PostgreSQL 17 — Failover. Reviewed October 15, 2026.