Check PostgreSQL rewind prerequisites before modifying a former primary

Preserve a clear fallback and verify prerequisites before rewinding a former PostgreSQL primary.

Source facts

PostgreSQL 17 pg_rewind requires the target cluster to have data checksums or wal_log_hints enabled, along with full_page_writes. Its dry-run option performs the work without modifying the target directory. A failure during actual rewind can leave the target directory unusable; the documentation recommends taking a fresh backup in that case. Rewind also copies configuration files from the source, so recovery configuration may need correction before the target is restarted as a standby.

Source: PostgreSQL 17 — pg_rewind.

Applicability

This applies to PostgreSQL 17 pg_rewind after timeline divergence. It is a rejoin procedure for a qualified administrator, not an instruction to reconnect an old primary automatically.

DSE recommendation

DSE recommends documenting the authoritative source and preserving the former primary’s stopped state before evaluating rewind. Verify prerequisites and WAL availability, run the dry run, and agree on a fresh-base-backup fallback. Review copied configuration before startup, especially the settings that establish the standby role. Include a stopping condition for any uncertainty about source identity; recovery speed should not replace an explicit decision about which timeline the service will retain.

Verification

Rehearse divergence and rejoin with disposable clusters. Record prerequisite checks, dry-run output, the actual operation’s result, and the target’s verified standby state afterward. Confirm replication resumes from the intended source and keep the tested fresh-backup fallback available if rewind cannot finish safely.

Official reference

PostgreSQL 17 — pg_rewind. Reviewed October 15, 2026.