57014 — canceling statement due to statement timeout

PostgreSQL statement_timeout can raise 57014 and leave the connection open; inside BEGIN, the failed transaction needs rollback or valid savepoint recovery before ordinary statements can continue.

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 standalone SELECT receives 57014, and a later standalone query succeeds. That says nothing about continuing inside a failed BEGIN block. The full Scenario also changes balance inside BEGIN, times out, observes 25P02, rolls back, and asserts the original balance 100. Recovery to a valid savepoint is a separate option. The timeout code can also mean query cancellation; a code alone does not identify the cause. Choosing a deadline or raising a limit is application advice, not a measured safe threshold.

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

MySQL's max_execution_time applies to eligible read-only SELECTs outside stored programs. Its 3024 error is documented, but not emitted by a Scenario here; the MySQL timeout lesson asserts SLEEP interruption instead. PostgreSQL statement_timeout covers other statements too. Neither demonstration measures all cancellation timing or recovery branches.