57P02
PostgreSQLFATALCommonOperator InterventionHIGH confidence

crash shutdown

Production Risk

High: service unavailable during crash recovery; potential data loss if WAL is corrupted.

What this means

SQLSTATE 57P02 is raised when the Postgres server is in crash recovery mode — typically following an unclean shutdown or server crash. All connections are terminated and the server replays WAL to restore consistency before accepting new connections.

Why it happens
  1. 1Postgres server crashed (OOM kill, hardware fault, SIGKILL)
  2. 2Server restarted after an unclean shutdown
  3. 3Postgres is in crash recovery / WAL replay mode
How to reproduce

Postgres recovering from a crash.

expected output

FATAL:  the database system is in recovery mode

Fix 1

Wait for recovery to complete before reconnecting

WHEN When Postgres is in crash recovery.

Why this works

Postgres automatically replays WAL to restore a consistent state. Monitor the server log for the "database system is ready to accept connections" message, then reconnect.

Fix 2

Investigate the root cause of the crash

WHEN After recovery completes.

Why this works

Review system logs (dmesg, journald) and Postgres logs for OOM events, hardware errors, or misconfiguration that caused the crash. Fix the root cause to prevent recurrence.

What not to do

Kill postgres processes manually during recovery

Interrupting crash recovery can prevent the database from reaching a consistent state and cause data loss.

Sources
Official documentation ↗

Class 57 — Operator Intervention (Postgres-specific)

Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev

← All PostgreSQL errors