57P04 — database_dropped

Source-backed reference entry for PostgreSQL SQLSTATE 57P04.

57P04

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.

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	`—`

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

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

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

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

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.

57P03, 57P02, 40001

Sources

src/backend/tcop/postgres.c#L3233-3248

src/backend/tcop/postgres.c#L2549-2578

The structured evidence record records the SQLSTATE guard, dynamic detail, and source/runtime boundary.