# 57P02 — crash_shutdown

> Source-backed reference entry for PostgreSQL SQLSTATE 57P02.
---

# 57P02

## At a glance {#at-a-glance}
`57P02` is the crash-shutdown path. When a crash-and-restart cycle is in progress, the backend sends a client-only WARNING describing the postmaster command to roll back and exit, then exits without running normal cleanup callbacks because shared memory may be corrupted.

<!-- BEGIN SQLSTATE FACTS: generated by scripts/generate.py; do not edit -->

| Field | Value |
| --- | --- |
| SQLSTATE | `57P02` |
| Condition | `crash_shutdown` |
| Status | `active` |
| Known present by | `7.4` |
| Locked snapshots | `9.0.23, 9.1.24, 9.2.24, 9.3.25, 9.4.26, 9.5.25, 9.6.24, 10.23, 11.22, 12.22, 13.23, 14.24, 15.19, 16.15, 17.11, 18.6, 19beta3` |
| Macros | `ERRCODE_CRASH_SHUTDOWN` |
| Aliases | `—` |

<!-- source facts: data/errcodes/57P02.json -->
<!-- END SQLSTATE FACTS -->

## Meaning {#meaning}
The fixed primary is `terminating connection because of crash of another server process`. Its detail says the postmaster ordered rollback and exit because another server process exited abnormally and possibly corrupted shared memory; its hint says to reconnect in a moment. The source uses `WARNING_CLIENT_ONLY` rather than FATAL so the signal handler can report to the client before forcing the process exit. The connection nevertheless closes, and no ordinary session-level recovery command can be sent afterward.

## Messages {#messages}

- Primary: `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.`
- Hint: `In a moment you should be able to reconnect to the database and repeat your command.`
- Severity source: `WARNING_CLIENT_ONLY`, a client-visible warning that is not sent to the server log; process exit follows the report. It is therefore not a claim that this path is a recoverable statement-level WARNING.

## Diagnosis {#diagnosis}
Correlate the SQLSTATE and full diagnostic with postmaster crash/recovery logs, backend PID, and the command in flight. The source explicitly orders rollback of the current transaction, but the client still must verify durable business state before replaying a non-idempotent request because the connection dies during the crash cycle. Distinguish this condition from orderly administrator shutdown (`57P01`) and startup refusal (`57P03`).

## Response {#response}
Do not try to send `ROLLBACK` on the dead connection or manufacture a crash to test the path. Wait for postmaster recovery/readiness, establish a new connection, inspect durable business state and affected objects, and retry only after the operation is idempotent or its prior effect is known. Preserve the primary/detail/hint and server logs for incident diagnosis.

## Versions {#versions}
The locked catalogue records this condition from 7.4; that boundary does not prove the exact implementation-introduction version. Fixed source coverage is PostgreSQL 18.6.

## Related {#related}
[`57P01`](../57p01/), [`57P03`](../57p03/), [`08006`](../08006/)

## Sources {#sources}
[`src/backend/tcop/postgres.c#L2974-3001`](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/tcop/postgres.c#L2974)

[`src/include/utils/elog.h#L46-55`](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/include/utils/elog.h#L46)

The structured [evidence record](../data/evidence/57p02.json) records the fixed message and the source/runtime boundary.