ERROR: canceling statement due to statement timeout (SQLSTATE 57014) means a statement ran longer than statement_timeout and the server stopped it. The limit is set somewhere, for example in the session or on the role you log in with. Make the statement faster, or raise the limit for that one transaction with SET LOCAL statement_timeout.

First find the limit with SHOW statement_timeout in the same connection. Then decide: a report that legitimately takes minutes gets its own higher limit; a query that should take milliseconds needs an index, not a bigger number.

The error

SET statement_timeout = '2s';
SET
SHOW statement_timeout;
 statement_timeout
-------------------
 2s
(1 row)

SELECT pg_sleep(5);
psql:/tmp/q5.sql:4: ERROR:  canceling statement due to statement timeout

Why it happens

statement_timeout is a safety net against runaway queries. When a statement exceeds it, the server cancels that statement and returns 57014. Here the pg_sleep(5) stood in for a slow query against a two-second limit.

The limit often comes from somewhere you did not look. A role setting applies to every new connection of that role: after ALTER ROLE report_user SET statement_timeout = '1s', a fresh session as report_user showed 1s and SELECT pg_sleep(3) was cancelled with the same message. Inside a transaction the timeout also aborts the transaction: the next statement failed with current transaction is aborted, commands ignored until end of transaction block until ROLLBACK.

The fix

BEGIN;
BEGIN
SET LOCAL statement_timeout = '10s';
SET
SELECT pg_sleep(5);
 pg_sleep
----------

(1 row)

COMMIT;
COMMIT
SHOW statement_timeout;
 statement_timeout
-------------------
 2s
(1 row)

SET LOCAL lasts until the end of the transaction, so the five-second statement finished and the session went back to its 2s limit afterwards, as the final SHOW proves. That keeps the safety net for everything else. Removing the timeout everywhere is the wrong fix; when the slow statement is a real query, look at its plan with EXPLAIN ANALYZE first. From .NET, Npgsql surfaces the cancellation as a PostgresException with SqlState 57014.

How it was reproduced

A postgres:18 container (PostgreSQL 18.4, Debian build 18.4-1.pgdg13+1) on Docker 29.9.2. One psql session set a 2s timeout and ran pg_sleep(5), once outside and once inside a transaction; the fix used SET LOCAL with 10s. A role report_user got a 1s timeout with ALTER ROLE and a new session as that role was cancelled on pg_sleep(3). A verbose run printed ERROR: 57014.

Frequently asked

How do I find where statement_timeout is set in PostgreSQL?
Run SHOW statement_timeout in the same connection to see the value in force. If your code never runs SET, check the role: ALTER ROLE name SET statement_timeout applies to every new session of that role.
How do I raise statement_timeout for one query only?
Wrap it in a transaction and run SET LOCAL statement_timeout = '10s' first. The setting ends with the transaction and the session returns to its previous limit.
Why does every statement fail after a statement timeout inside a transaction?
The timeout aborts the whole transaction. Later statements fail with current transaction is aborted until you run ROLLBACK and start again.

More decoded errors in the Fixes category. For the follow-up error inside a transaction, see current transaction is aborted (25P02).