SQLSTATE 57P01 — admin_shutdown: FATAL terminating connection due to administrator command

SQLSTATE 57P01 condition admin_shutdown class 57 — 57 — Operator Intervention severity FATAL
Reproduced & verified on PostgreSQL 14.23, 15.18, 16.14, 17.10 and 18.4 — identical message on every version.
Last reviewed 28 May 2026 · Reproduced live with the SQL on this page.

! Symptoms Free

Conditions:

  • Application errors: FATAL: terminating connection due to administrator command
  • PostgreSQL log shows LOG: connection received from ... terminated by administrator command
  • A DBA recently ran pg_terminate_backend() or pg_ctl stop
  • Or a monitoring script with a broad filter killed sessions

1 Environment & reproduce Free

Difficulty: Beginner  |  PostgreSQL versions: 12, 13, 14, 15, 16, 17

? Root cause Free

  • pg_terminate_backend() sends SIGTERM — the session gets FATAL: terminating connection due to administrator command and the transaction is rolled back.
  • pg_cancel_backend() is softer — sends SIGINT, cancels only the current statement, connection stays open. Prefer this for active queries.
  • A DBA using WHERE state = 'idle' kills ALL idle connections including healthy PgBouncer server-side connections — PgBouncer then reconnects, causing a connection storm.
  • pg_ctl stop -m fast terminates all connections immediately. Use maintenance windows and notify applications first.
  • pg_ctl stop -m smart waits for all connections to finish — safer but may wait indefinitely.

Use pg_cancel_backend() instead of pg_terminate_backend() for active queries. Only terminate specific PIDs after manual review. Set idle_in_transaction_session_timeout to auto-kill stuck sessions without manual intervention.

2 Diagnose Free

RESULT
-- Check who has pg_signal_backend privilege (can terminate connections):
SELECT rolname, rolsuper
FROM pg_roles
WHERE rolsuper = true OR pg_has_role(rolname, 'pg_signal_backend', 'MEMBER')
ORDER BY rolname;

-- Check recent connection terminations in log:
-- grep "terminating connection" $PGDATA/pg_log/postgresql-$(date +%Y-%m-%d).log

-- Safe way to terminate only truly idle/stuck sessions:
SELECT pid, usename, state, now() - query_start AS duration
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND query_start < now() - INTERVAL '10 minutes'
  AND usename != 'postgres';    -- never kill postgres sessions blindly

🔒 Diagnose deeper Pro

🔒

Find every latent occurrence before it ships

The steps above clear this incident. Pro adds the executed, verified depth that stops the whole class of bug across your fleet.

  • ✓Catalog & log queries that surface every at-risk object before a migration ships.
  • ✓Inspect-without-running tricks (\gdesc and friends).
  • ✓Exactly where the log line surfaces on RDS, Azure & Cloud SQL.
  • ✓Cross-version gotchas, verified on PostgreSQL 14–18.
Unlock Pro from $24.99/mo · or $199/yr — unlocks every Pro section.

Every Pro query on this site is executed against real PostgreSQL and verified — we never publish an untested snippet.

3 Recovery & verify Free

Use pg_cancel_backend() instead of pg_terminate_backend() for active queries. Only terminate specific PIDs after manual review. Set idle_in_transaction_session_timeout to auto-kill stuck sessions without manual intervention.