PostgreSQL Operator Intervention (SQLSTATE 57000)

When a database administrator (or an automated tool acting as one) explicitly cancels or terminates a backend process, PostgreSQL raises an error in SQLSTATE class 57 — Operator Intervention. The top-level condition is operator_intervention (SQLSTATE 57000), which serves as the parent class for more specific child conditions. Applications will typically see a message such as:

ERROR:  operator intervention
SQLSTATE: 57000

However, in practice you will almost always see one of the child conditions rather than the bare 57000 code itself.

What This Error Means

SQLSTATE class 57 groups errors that are triggered by deliberate administrative actions rather than bugs in application SQL or data violations. The class 57000 condition (operator_intervention) is the generic parent; its child conditions include 57014 (query_canceled) and 57P01/57P02/57P03, which correspond to admin_shutdown, crash_shutdown, and cannot_connect_now respectively.

When PostgreSQL raises any 57xxx error, the current transaction is aborted and cannot be continued. The connection itself may or may not survive depending on which child error occurred: a query_canceled (57014) leaves the connection open (the session continues in an aborted transaction state), while admin_shutdown (57P01) or crash_shutdown (57P02) terminate the connection entirely.

Because 57000 is a class-level code, receiving the bare 57000 SQLSTATE typically means the server raised an operator intervention that did not map to any of the named child conditions — this is uncommon in normal operation but can occur when extensions or custom code signal cancellation directly.

Common Causes

1. pg_cancel_backend(pid) — A DBA or monitoring script sent a cancellation signal to a running backend. This raises 57014 (query_canceled) but is caught by 57000 handlers if code catches the parent class.
2. pg_terminate_backend(pid) — The backend process was forcibly terminated. This raises 57P01 (admin_shutdown) and drops the connection.
3. statement_timeout or lock_timeout expiry — PostgreSQL internally cancels the query when a timeout fires, raising 57014. This is the most common way application code encounters a 57xxx error.
4. idle_in_transaction_session_timeout expiry — Sessions left open in an idle transaction are terminated by the server after the configured timeout, raising 57P01.
5. Server shutdown or restart — When PostgreSQL shuts down (fast or smart mode), active connections receive 57P01 (admin_shutdown).
6. Custom extensions or pg_cancel_backend called from triggers/functions — Rare, but possible in environments where monitoring extensions (e.g., pg_cron, pg_background) manage long-running queries automatically.

How to Fix operator_intervention

1. Identify the specific child SQLSTATE. Application logs should show the full SQLSTATE code. 57014 means the query was cancelled; 57P01 means the connection was terminated. Knowing which one occurred narrows down the cause significantly.

2. Check pg_stat_activity for cancelled queries — query the view immediately after the error if possible, or review log_min_duration_statement output to find long-running queries that triggered a timeout:

   SELECT pid, state, wait_event_type, wait_event, query_start, query
   FROM pg_stat_activity
   WHERE state != 'idle'
   ORDER BY query_start;
   

3. Review and tune timeout settings — if statement_timeout or lock_timeout is firing more than expected, investigate slow queries rather than simply raising the timeout:

   -- Check current timeout settings
   SHOW statement_timeout;
   SHOW lock_timeout;
   SHOW idle_in_transaction_session_timeout;
   

4. Optimize the query being cancelled — use EXPLAIN (ANALYZE, BUFFERS) to find sequential scans or missing indexes that make the query exceed timeouts:

   EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
   SELECT ...;  -- the query that was cancelled
   

5. Handle the error in application code — connections receiving 57P01 (admin_shutdown) are dead and must be discarded. Connection pools should detect this and remove the connection. For 57014 (query_canceled), the session is still alive but the transaction is aborted — issue a ROLLBACK before retrying:

   ROLLBACK;
   -- then retry the transaction
   

6. Check PostgreSQL server logs — when a backend is terminated by a DBA, the server log records which role executed pg_terminate_backend and the target PID. Correlate timestamps with your application error to confirm the root cause.

Additional Information

• SQLSTATE class 57 child conditions: 57014 (query_canceled), 57P01 (admin_shutdown), 57P02 (crash_shutdown), 57P03 (cannot_connect_now). In practice, 57000 bare is almost never seen; always inspect the full code.
• The bare 57000 condition has existed since PostgreSQL 7.4 when the SQLSTATE system was formalized.
• Most PostgreSQL client drivers (libpq, psycopg2, asyncpg, JDBC) surface 57014 as a distinct exception class (e.g., QueryCanceledError in psycopg2, PSQLException with SQLState 57014 in JDBC). Catching the parent 57000 catches all operator intervention variants.
• ORMs such as Django (via psycopg2) and SQLAlchemy raise OperationalError wrapping these codes; inspect pgcode on the underlying exception to distinguish 57014 from 57P01.
• Connection poolers (PgBouncer, pgpool-II) should be configured with appropriate server-side keepalives and timeouts so that terminated backends are detected promptly and not handed to clients.
• In high-availability setups (Patroni, repmgr), a primary failover will generate 57P01 or 57P02 errors on all active connections — ensure your application's retry logic handles these codes specifically.

Frequently Asked Questions

Why does my application see 57000 instead of 57014 or 57P01? Some database drivers or abstraction layers catch the SQLSTATE class (57) and report the parent code 57000 rather than the specific child. Check whether your driver or ORM exposes the full SQLSTATE string, or inspect the raw server error message which always includes the specific code.

Is 57000 a fatal error that drops my connection? It depends on the child condition. 57014 (query_canceled) is non-fatal — the connection remains open but the current transaction is aborted and must be rolled back before you can continue. 57P01 (admin_shutdown) and 57P02 (crash_shutdown) do drop the connection and require reconnection.

My queries are being cancelled by statement_timeout — should I just increase the timeout? Increasing the timeout treats the symptom, not the cause. First investigate why the query is slow using EXPLAIN ANALYZE. Missing indexes, table bloat, or locking contention are common culprits. A timeout that fires consistently is a signal of a performance problem, not a configuration problem.

Can I catch operator_intervention in a PL/pgSQL function? Yes. Use an EXCEPTION block with WHEN operator_intervention (or the more specific WHEN query_canceled) to handle it:

BEGIN
  -- your statement
EXCEPTION
  WHEN query_canceled THEN
    -- handle cancellation
  WHEN operator_intervention THEN
    -- handle other admin interventions
END;

Note that catching query_canceled inside PL/pgSQL does not prevent the surrounding transaction from being aborted if the cancel was issued from outside the function.