Lesson 7 of 14

pg_rewind: Reusing a Diverged Old Primary

Applies to PostgreSQL 13–17 Last reviewed May 2026 Grounded in source

The one thing to understand first

When a standby is promoted to primary (after the old primary failed or was isolated), the cluster has a new leader on a new timeline. If the old primary comes back, it has diverged: it may contain transactions that were never replicated, and it is on the old timeline. You cannot simply reconnect it as a standby — its history conflicts with the new primary. Historically the only fix was a full pg_basebackup rebuild, copying the entire database. pg_rewind avoids that.

pg_rewind copies only the data blocks that actually diverged since the split point — not the whole database. It turns a multi-hour rebuild of a failed primary into minutes, by discarding (not recovering) the old primary’s unreplicated writes.

What divergence looks like

            ... common history ...  <- divergence point (LSN)
old primary:                       \--- A, B  (transactions never replicated)
new primary (promoted):            \--- X, Y, Z  (new timeline)

The two servers agree up to the divergence point, then differ. To reuse the old primary, you must undo its divergent changes (A, B) and bring it in line with the new primary so it can stream from it.

This is a Pro lesson

Get every Learning Pathway and cookbook recipe — grounded in PostgreSQL source code, with diagnostics, fixes, and prevention for each topic.

Continue this lesson to learn:

  • How pg_rewind works
  • Prerequisites
  • Layer 3 — Watch it happen on your own database
  • Layer 4 — The levers this hands you
  • Layer 5 — What an Oracle DBA should expect vs what they get
  • Key takeaway
  • All 36 Learning Pathway lessons
  • 170+ cookbook recipes
  • Source-grounded diagnostics & fixes

Secure checkout Cancel anytime Source-grounded

Was this helpful?

← Back to 04 — Advanced: Replication & HA Architecture