crash_shutdown terminating connection because of crash of another server process — 57P02

Symptoms

Another backend crashed, so the postmaster reset shared memory and terminated all sessions to guarantee a consistent state. PostgreSQL raises SQLSTATE 57P02 (crash_shutdown).

• All connections are dropped at once.
• A DETAIL/HINT explains shared memory may be corrupted and the server is recovering.
• The server automatically restarts and runs crash recovery.

What the server log shows

WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.

Why PostgreSQL raises this — what the manual says

Section 18.5 Shutting Down the Server:

“This will lead to recovery (by replaying the WAL log) upon next start-up.”

Because backends share memory, one crashing process could leave shared structures inconsistent. The postmaster defensively terminates every session (57P02), reinitializes shared memory, and performs crash recovery from WAL before accepting connections again.

Common causes

• A backend crash (segfault, OOM killer, bug, or hardware fault).
• The OOM killer terminating a PostgreSQL process.
• An extension or corrupted data triggering a fatal fault.

How to fix it

1. Reconnect after the server completes crash recovery.
2. Check the server log and OS logs for the crashing process and root cause.
3. Address OOM (tune memory/overcommit) or buggy extensions; ensure hardware is healthy.

Related & next steps

• SQLSTATE 57P02 — Crash Shutdown (full reference)
• Message: out of memory
• Glossary: Crash recovery

Reference: PostgreSQL 18 Section 19.3 “Shutting Down the Server”.