Postgres "Canceling Statement Due to Statement Timeout" Fix

"Canceling statement due to statement timeout" means a configured statement_timeout deliberately killed a query that ran longer than allowed — the right fix depends on whether the query is genuinely, legitimately slow and needs more time, or whether it's slow because of a fixable underlying performance issue that a longer timeout would only mask.

The Problem

A query is terminated before completing, with:

ERROR: canceling statement due to statement timeout

The same or similar queries might have worked fine before, or work fine against smaller datasets, pointing at either data growth outpacing an existing timeout setting, or a specific query that's genuinely more expensive than the current timeout allows.

Why It Happens

statement_timeout is a safety setting that prevents any single query from running indefinitely, protecting against runaway queries consuming server resources without bound. It can be set globally, per-database, per-role, or per-session, and the error appears whenever a query's actual execution time exceeds whatever value is currently in effect for that specific connection. Common reasons this starts appearing:

• Data volume has grown over time, and a query that used to comfortably complete within the timeout now genuinely takes longer against the larger dataset
• A missing or ineffective index causes a query to perform a full table scan or an inefficient join, making it dramatically slower than it should be for what it's actually trying to accomplish
• The timeout itself was set very conservatively (a short value) for a specific, narrower use case, but is now also applying to a different, legitimately more expensive type of query sharing the same connection or role configuration
• Lock contention is causing the query to spend a significant portion of its time waiting on a lock held by another transaction, rather than the query's own logic itself being inherently slow

The Fix

First, determine whether the query is slow because of a genuine performance problem that should be fixed, versus being inherently expensive and legitimately needing more time. Check the query plan:

EXPLAIN ANALYZE SELECT ...; -- run without hitting the timeout, if possible, to see the full plan

If EXPLAIN alone (without ANALYZE, which actually runs the query) reveals an obviously inefficient plan — a sequential scan where an index should apply, an inefficient join order — the real fix is addressing that underlying issue (adding an index, rewriting the query) rather than simply extending the timeout to accommodate an inefficient execution path.

If the query is confirmed to be genuinely, appropriately expensive for legitimate reasons (a complex report, a large aggregate calculation that has no faster equivalent), raise the timeout specifically for that use case, rather than globally for the entire database — scope the change as narrowly as possible:

SET statement_timeout = '5min';
-- run your specific long-running query within this same session

For a more persistent, targeted scope, set an elevated timeout for a specific role used exclusively for legitimately longer-running operations (like a reporting role, separate from your main application's regular role), rather than raising the global default that applies to every connection:

ALTER ROLE reporting_user SET statement_timeout = '10min';

Keeping the default timeout conservative for your main application role, while allowing a specifically scoped, higher timeout only for roles/contexts that genuinely need it, preserves the general safety benefit of having a timeout at all, rather than removing that protection broadly just to accommodate one specific slow query type.

If lock contention is contributing to the slowness (confirmed by checking pg_stat_activity for the query spending significant time in a waiting state rather than actively executing), address the underlying contention — often by reviewing why another transaction is holding a conflicting lock for an extended period — rather than simply extending the timeout to work around symptoms of that contention:

SELECT pid, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE state = 'active' AND wait_event IS NOT NULL;

Still Not Working?

If you've optimized the query as much as reasonably possible and it still occasionally exceeds even a generously raised timeout under certain conditions (like unusually high concurrent load), consider whether the operation should be restructured to run asynchronously in the background rather than as a synchronous, timeout-bound query at all — for genuinely long-running operations (large exports, complex batch processing), a background job pattern that the user polls for completion is often architecturally more robust than continuing to raise a synchronous query's timeout indefinitely to accommodate worst-case execution time under peak load.