# 57P04 — database_dropped

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

# 57P04

## At a glance {#at-a-glance}
`57P04` is selected when a recovery conflict terminates a session because the connected database must be dropped. The same recovery-conflict primary is used for other conflict reasons, but those branches select `40001`; the database-dropped guard is the condition identity that matters here.

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

| Field | Value |
| --- | --- |
| SQLSTATE | `57P04` |
| Condition | `database_dropped` |
| Status | `active` |
| Known present by | `9.0.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_DATABASE_DROPPED` |
| Aliases | `—` |

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

## Meaning {#meaning}
The fixed call site uses FATAL with primary `terminating connection due to conflict with recovery`, dynamic recovery-conflict detail, and hint `In a moment you should be able to reconnect to the database and repeat your command.`. The SQLSTATE expression is explicit: `ERRCODE_DATABASE_DROPPED` is selected only when `reason == PROCSIG_RECOVERY_CONFLICT_DATABASE`; other reasons in this terminating branch use `ERRCODE_T_R_SERIALIZATION_FAILURE`. For the database branch, the detail is `User was connected to a database that must be dropped.`.

## Messages {#messages}

- Primary: `terminating connection due to conflict with recovery`, FATAL.
- Database-drop detail: `User was connected to a database that must be dropped.`
- Hint: `In a moment you should be able to reconnect to the database and repeat your command.`
- Other recovery-conflict reasons can reuse the primary but select `40001` and a different detail; do not label them `57P04` from the primary alone.

## Diagnosis {#diagnosis}
Preserve SQLSTATE, primary/detail/hint, database name, backend PID, recovery-conflict reason, and standby/recovery logs. Confirm that the detail identifies the dropped database before treating the condition as `57P04`. The FATAL report closes the connection, so there is no session in which to issue `ROLLBACK`. Check whether the interrupted operation could have committed before disconnection.

## Response {#response}
Wait for the recovery conflict/database transition to clear, reconnect to a valid database, and verify durable business state before replaying a non-idempotent operation. If the server reports another recovery-conflict detail with `40001`, apply serialization/retry handling instead. Do not repeatedly reconnect while the database is still being dropped or while recovery logs show the conflict is active.

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

## Related {#related}
[`57P03`](../57p03/), [`57P02`](../57p02/), [`40001`](../40001/)

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

[`src/backend/tcop/postgres.c#L2549-2578`](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/tcop/postgres.c#L2549)

The structured [evidence record](../data/evidence/57p04.json) records the SQLSTATE guard, dynamic detail, and source/runtime boundary.