Menu

PostgreSQL Error 57P01: Admin Shutdown

Troubleshoot PostgreSQL 57P01, “terminating connection due to administrator command,” by checking backend termination, shutdown, and failover events.

Posted on By
On this page

PostgreSQL SQLSTATE 57P01 is admin_shutdown. A common message is FATAL: terminating connection due to administrator command. It means PostgreSQL is terminating the current connection after an administrative action; it is not a SQL syntax error or a password failure. PostgreSQL lists the code in its error-code appendix.

Check whether the server or this backend was terminated

Inspect the PostgreSQL server log and the service manager or managed-database event log around the error time. The cause may be a server shutdown, maintenance operation, failover, container or process restart, or an administrator terminating this particular backend with pg_terminate_backend(). PostgreSQL documents backend termination separately from whole-server shutdown. Shutdown modes also differ: smart shutdown stops accepting new connections and waits for sessions to finish, while fast shutdown aborts active transactions and exits promptly. See Shutting Down the Server.

If the service is still stopping or starting, do not keep retrying against the same endpoint. Wait for the service or failover target to become ready, then verify it with pg_isready using the same host and port as the application. A readiness check does not validate the application’s credentials; see PostgreSQL Error 57P03: cannot connect now.

If you did not expect a shutdown, correlate the PostgreSQL logs with orchestration, hosting-provider maintenance, and monitoring events. Repeated restarts can indicate a health-check loop or an external controller repeatedly replacing the database process.

Restore application connections without blind write retries

A connection closed by a server shutdown is no longer usable. Application pools should discard the failed connection and establish a new one after the server is ready. Use bounded retry with a delay so a restart or failover does not create a connection storm.

An interrupted transaction may have been aborted, but a client that loses its connection while a write or COMMIT is in flight must verify the operation’s outcome before repeating a non-idempotent action. Use a request or idempotency key, or query for the result using an application-specific identifier. For the broader case where the client cannot determine whether the connection or transaction completed, see PostgreSQL Error 08006: connection failure.

  • 57P01 — admin_shutdown: PostgreSQL terminated the current connection in response to a shutdown request.
  • 57P02 — crash_shutdown: PostgreSQL terminated sessions during a crash-related shutdown; see Error 57P02 troubleshooting.
  • 57P03 — cannot_connect_now: a new connection reached PostgreSQL, but the server was not accepting it yet, commonly during startup or recovery.
  • 08006 — connection_failure: a broader connection failure; the code alone may not identify whether the server, network, proxy, or client closed the connection.

For other SQLSTATE guides, browse PostgreSQL Error Troubleshooting.