57014 — canceling statement due to statement timeout

PostgreSQL raises 57014 when statement_timeout cancels a statement that ran longer than the limit, leaving the session and its transaction alive, so you retry the statement or raise the ceiling.

Reproduce it

This one needs only a single session, since a statement timeout is a per-statement seatbelt, not a race between transactions.

-- cap any one statement at 100ms
SET statement_timeout = '100ms';

-- then run something that takes two seconds
SELECT pg_sleep(2);

The SELECT is canceled at the 100ms mark with ERROR: 57014: canceling statement due to statement timeout. Nothing else dies: the connection is still open and the transaction (if you were in one) still holds its state, so a SELECT 'still here' right after works fine. That's the whole point of statement_timeout: it kills a runaway query without tearing down the session around it. You either retry with a real deadline in mind or lift the limit for the query that genuinely needs longer.

Run it yourself

The Long & idle transactions lesson renders this scenario as a verified transcript and contrasts it with transaction_timeout, which does tear the whole backend down. For where these guardrails fit when you're diagnosing a stuck system, see Symptom triage.

The MySQL side

There's no exact match in the proven set. MySQL's closest lever is max_execution_time (which raises error 3024), and it's narrower: it caps SELECT statements only, where PostgreSQL's statement_timeout applies to any statement. The MySQL long & idle transactions lesson covers it, but no page here claims 3024, because no scenario on this site emits it yet.