57P01 — admin_shutdown

Source-backed full entry for PostgreSQL SQLSTATE 57P01.

57P01

At a glance

57P01 is a server-initiated administrative-shutdown condition. Fixed core paths cover orderly or immediate client termination, worker/parallel termination, and a synchronous-replication wait that explicitly says the transaction has already committed locally but might not have been replicated to the standby.

Field	Value
SQLSTATE	`57P01`
Condition	`admin_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_ADMIN_SHUTDOWN`
Aliases	`—`

Meaning

The SQLSTATE is reused at several lifecycle boundaries, so severity and recovery depend on the call site. The immediate-stop signal path sends a client-only WARNING and then exits without normal cleanup; the ordinary client administrator-command path uses FATAL. The synchronous-replication path uses WARNING and includes the detail The transaction has already committed locally, but might not have been replicated to the standby. That warning is followed by connection termination. Parallel and worker paths use their own FATAL or worker control flow. These are not interchangeable statements about whether a business operation committed.

Messages

Immediate stop: primary terminating connection due to immediate shutdown command, severity WARNING_CLIENT_ONLY; the process exits after reporting.
Client backend administrator command: primary terminating connection due to administrator command, severity FATAL; the connection closes.
Synchronous replication wait: primary canceling the wait for synchronous replication and terminating connection due to administrator command, severity WARNING, detail The transaction has already committed locally, but might not have been replicated to the standby.
Parallel transaction: primary postmaster exited during a parallel transaction, severity FATAL.
Another fixed promotion wait branch reports terminating connection due to unexpected postmaster exit at FATAL with context while waiting on promotion.

Diagnosis

Correlate the complete primary/detail/context, backend PID, administrator or postmaster action, server shutdown/recovery log, and transaction boundary. The selected runtime case covers only the client-backend administrator-command branch. It does not prove the immediate-stop, synchronous-replication, worker, parallel, or promotion outcomes. When the synchronous-replication detail appears, the transaction has already committed locally while remote standby replication is uncertain; query durable state and replication status before replaying a non-idempotent operation. The warning path still terminates the connection, so the old session cannot be used for recovery.

Response

For a FATAL or client-only shutdown report, the connection is not a transaction recovery point: wait for readiness, open a fresh connection, and inspect durable business state or an idempotency key before retrying. For the synchronous-replication branch, preserve the warning, record that local commit has already occurred, and determine standby receipt separately; the connection is still terminated after the warning. Do not assume any 57P01 path leaves a live session for recovery. The accepted case’s fresh SELECT 1 proves readiness after terminating the targeted victim, not that an interrupted business operation committed.

Observed diagnostics

The selected registry created a runner-owned victim client backend, a distinct administrator session, and a fresh session on PostgreSQL 18.6 and 10.21. The admin verified the target identity and pg_terminate_backend returned true. The victim driver reported FATAL / 57P01 with terminating connection due to administrator command and closed; the fresh session returned 1 and was IDLE. This bounded case does not cover the other source branches or business commit outcome.

Representative case

Use only the PID returned by the case-created victim session; never substitute an arbitrary production PID or the administrator’s own PID. The fresh probe verifies server reachability after the targeted termination. Check durable business state or an idempotency key before replaying a non-idempotent request.

-- victim session created by the case runner
SELECT pg_backend_pid();  -- save as :victim_pid
SELECT 1;                 -- probe before termination

-- admin session; record its own PID, then use only the runner-created victim PID
SELECT pg_backend_pid(); -- save as :admin_pid
SELECT pid, backend_type FROM pg_stat_activity WHERE pid = backend_pid;
SELECT pg_terminate_backend(backend_pid);

-- fresh session after the victim disconnects
SELECT 1;

Versions

The locked catalogue records this condition from 7.4; that catalogue boundary does not prove the exact implementation-introduction version. Fixed source coverage is PostgreSQL 18.6, with the selected runtime case also observed on PostgreSQL 10.21.

57P02, 57P03, 40001