57P02FATALTier 1 — Safe✅ HIGH confidence

crash shutdown

Category: Operator InterventionVersions: All Postgres versions

🔴 Production Risk Error

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

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

How to reproduce

Postgres recovering from a crash.

trigger — this will ERROR

FATAL: the database system is in recovery mode

Fix 1: Wait for recovery to complete before reconnecting

When Postgres is in crash recovery.

fix

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

After recovery completes.

fix

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

Why it's wrong: Interrupting crash recovery can prevent the database from reaching a consistent state and cause data loss.

Dangerous variant

⚠️ Warning

57P02 following data directory corruption — data loss risk

Sources

📚 Official docs: https://www.postgresql.org/docs/current/errcodes-appendix.html

🔧 Source ref: Class 57 — Operator Intervention (Postgres-specific)

Confidence assessment

✅ HIGH confidence

Postgres-specific. Well-documented crash recovery behaviour.