PostgreSQL Error 57P02: Crash Shutdown

PostgreSQL SQLSTATE 57P02 is crash_shutdown. A common client warning is terminating connection because of crash of another server process. PostgreSQL sends this while the postmaster is forcing backend processes to exit after one process failed abnormally. The notice identifies the crash shutdown, not the original process failure; see PostgreSQL’s error-code appendix and PostgreSQL 18 server code.

Find the first server-process failure

Look earlier than the client-facing 57P02 notice in the PostgreSQL server log. The postmaster coordinates server processes; when a process exits abnormally, PostgreSQL tells the other server processes to terminate so that shared state is not used after a crash. The original error, signal, or PANIC entry is usually more useful than the later connection-termination message. See the postgres server process documentation.

For a managed database or container, check the provider event log and orchestration logs at the same timestamp for a process restart, failover, resource limit, health-check action, or host-level termination. If this was unexpected or repeats, involve the database operator; do not treat it as an application password or SQL syntax problem.

Wait for crash recovery before reconnecting

After a crash-related shutdown, PostgreSQL may need to replay WAL during startup. Check service logs for recovery progress and a ready state. Once the service responds, use pg_isready against the application’s host and port to check whether new connections are accepted. A ready response does not validate the application credentials; see the pg_isready documentation.

Do not manually remove server files, send SIGKILL, or run pg_resetwal as routine recovery steps. pg_resetwal is a last resort for a server that cannot start due to WAL or control-file corruption, and using it can leave the database inconsistent. Follow the provider’s recovery process or the database operator’s instructions; see the pg_resetwal warning.

Reconcile interrupted transactions and reconnect safely

Transactions that had not committed when their backend was terminated are rolled back. If the client lost its connection while a write or COMMIT was in progress, verify the operation’s outcome before retrying a non-idempotent request; see PostgreSQL Error 08006: connection failure.

After recovery, the connection pool should discard failed sessions and reconnect with bounded backoff. If the server reports that an administrator intentionally shut it down, see PostgreSQL Error 57P01: admin shutdown. If it is reachable but still starting, see PostgreSQL Error 57P03: cannot connect now.

For other SQLSTATE guides, browse PostgreSQL Error Troubleshooting.