High availabilityadvancedPro runbook

What happens when your synchronous standby dies

With synchronous_standby_names set and the standby gone, commits park on wait_event SyncRep and the client never gets an ack. Cancelling that wait does not roll back — PostgreSQL warns the transaction already committed locally, and the row appears.

Problem

What you're actually looking at

The symptom as it shows up on a real server.

Synchronous replication is usually explained as a durability setting. Operationally it is an availability setting: when the only synchronous standby is unreachable, every commit waits for an acknowledgement that cannot arrive. The database is up, queries read fine, and writes simply stop returning. The instinct is to cancel the stuck statement, and that instinct silently converts a synchronous commit into an asynchronous one.

Meridian runs one synchronous standby. It is stopped for maintenance and the application's writes stop completing, with no error to point at. An engineer cancels the hung session to unblock the queue.

In plain English

Synchronous replication means PostgreSQL promises not to tell you a write succeeded until a second server also has it. If that second server disappears, the promise cannot be kept, so PostgreSQL waits instead of lying — your write hangs. The subtle part is what happens if you give up and cancel: the change was already written and made durable on the primary, so cancelling does not undo it. It only stops waiting for the replica. The row is now live on the primary and missing from the replica, which is exactly the row you lose if you fail over next.

ProCaptured evidence where the run produced it

Full runbook for this incident

The scenario above is free. What Pro unlocks is the fix: how to identify what happens when your synchronous standby dies, the exact SQL to trace it, PostgreSQL 18 output for the steps we captured, the resolution path, and how to stop it recurring.
  • The full identify checklist — the exact signals that tell you it's this incident
  • Every diagnostic query; PostgreSQL 18 output is attached only to the steps we captured
  • The resolution path and the pitfalls that make it worse
  • Mitigation steps to stop it recurring, plus a verify-you're-done query

More in this category

Other High availability runbooks

Neighbouring incidents that share the same diagnostic surface.

Browse all 84 runbooks →

Connected

How this connects to the rest of the library

A live view of this page's real cross-references — what explains it, what fixes it, what to tune, and where to go next. Every link is an authored relationship, not a guess.

Open in the interactive map →