How to fix Canceling statement due to statement timeout in PostgreSQL

PostgreSQLINTERMEDIATEMEDIUMUpdated Dec 29, 2025· 292 views

PostgreSQL error 57014 occurs when a query exceeds the configured statement_timeout limit and is automatically terminated. This protects the server from runaway queries. Increase the timeout, optimize the query, or check for locks causing delays.

Quick fix

Fixes 57014

SHOW statement_timeout;
  1. Check the current statement_timeout setting
  2. Increase the timeout for the current session
  3. For a single transaction, use SET LOCAL
  4. Optimize the query to run faster
postgresql — error
SHOW statement_timeout;
Canceling statement due to statement timeout

What this error means

Error 57014 (QUERY_CANCELED) is raised when PostgreSQL automatically cancels a query because it exceeded the maximum time allowed to execute. The statement_timeout parameter sets a limit on how long any single SQL statement is allowed to run. When a query surpasses this limit, PostgreSQL terminates it and returns this error to prevent long-running queries from consuming server resources indefinitely. By default, statement_timeout is set to 0 (disabled). However, many deployments or application frameworks set explicit timeouts to prevent runaway queries. The timeout applies individually to each SQL statement—if multiple statements are sent together, each statement has its own timeout countdown.

Typical symptoms

  • Query execution stops unexpectedly with "ERROR: canceling statement due to statement timeout"
  • Long-running reports or analytics queries fail after a few seconds
  • Data import or export operations get interrupted mid-process
  • Database backup or VACUUM operations are terminated
  • Migrations fail during large table operations
  • AWS DMS (Database Migration Service) fails with timeout errors during data synchronization

Common causes

  1. The statement_timeout value is set too low for the complexity of the query being executed
  2. Query is inefficient and taking longer than expected due to missing indexes or poor execution plans
  3. Database server is under heavy load or experiencing lock contention, slowing query execution
  4. Large table operations (INSERT, UPDATE, DELETE, VACUUM) take longer than the configured timeout allows
  5. Application or deployment platform (e.g., AWS RDS, Railway, Heroku) has a default timeout that is too short
  6. Network latency or database connection pool issues cause delays in query transmission or execution

How to fix "Canceling statement due to statement timeout"

1Check the current statement_timeout setting

First, determine what timeout limit is currently configured for your session or database.

sql
SHOW statement_timeout;

This will display the current timeout value (e.g., "60s", "30000ms", or "0" for disabled). Also check if it is set at different levels:

sql
-- Session level
SHOW statement_timeout;

-- Database level
SELECT datconfig FROM pg_database WHERE datname = 'your_database';
2Increase the timeout for the current session

If the timeout is genuinely too short for your query, increase it for your current session:

sql
SET statement_timeout = '120s';

You can use various time units: "us" (microseconds), "ms" (milliseconds), "s" (seconds), "min" (minutes), "h" (hours), or "d" (days). For example:
- SET statement_timeout = '5min'; — 5 minutes
- SET statement_timeout = '300000'; — 300 seconds (in milliseconds)
- SET statement_timeout = '0'; — Disable timeout (unlimited)

3For a single transaction, use SET LOCAL

If you only need to increase the timeout for a specific transaction or operation, use SET LOCAL. This change applies only to the current transaction and automatically reverts afterward:

sql
BEGIN;
SET LOCAL statement_timeout = '600s';
-- Your long-running query here
COMMIT;

This approach is safer and doesn't affect other sessions.

4Optimize the query to run faster

Rather than just increasing the timeout, investigate why the query is slow and fix the underlying performance issue.

Analyze the query execution plan:

sql
EXPLAIN ANALYZE
SELECT * FROM large_table WHERE expensive_condition;

Look for:
- Sequential scans where index scans would be better
- Missing indexes on frequently filtered columns
- Join operations that could be optimized

Create missing indexes:

sql
CREATE INDEX idx_column_name ON table_name(column_name);

Run ANALYZE to update statistics:

sql
ANALYZE table_name;

Optimizing the query is always preferable to increasing timeouts.

5Check for locks or other blocking queries

Sometimes timeouts occur because the query is blocked waiting for locks on tables. Check what is happening on the server:

sql
SELECT * FROM pg_stat_activity WHERE state = 'active';

This shows all active queries. If you see another query with waiting = true, it is waiting for a lock. To see what locks exist:

sql
SELECT * FROM pg_locks WHERE NOT granted;

If you identify a blocking query, you can terminate it (use with caution):

sql
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE pid != pg_backend_pid() AND query LIKE '%old_query%';
6Set statement_timeout at database or user level (if needed permanently)

If you want to increase the timeout for all sessions connecting to a specific database, use ALTER DATABASE:

sql
ALTER DATABASE your_database SET statement_timeout = '120s';

For all databases and users, modify postgresql.conf (requires server restart):

ini
statement_timeout = '120s'

Then reload the configuration:

sql
SELECT pg_reload_conf();

Note: Setting a global timeout is not recommended because it affects all sessions. Use session-level or database-level settings instead.

7For AWS DMS or migration tools, increase timeout in connection settings

If encountering this error during AWS DMS or other migration operations, the timeout may be enforced by the tool itself.

For AWS DMS:
- Increase the statement_timeout on the target database
- Use Task Settings > Advanced → Turn on BatchApplyEnabled for faster writes
- Increase LOB chunk size if migrating large objects

For application frameworks:
- Check your connection string for timeout parameters
- For Node.js (pg library): statement_timeout: 120000
- For Python (psycopg2): options='-c statement_timeout=120000'
- For Java (JDBC): socketTimeout=120000

Advanced notes

Understanding PostgreSQL Timeout Parameters: PostgreSQL provides several timeout settings beyond statement_timeout. The idle_in_transaction_session_timeout prevents sessions from staying idle inside a transaction, which can lock resources. The lock_timeout limits how long a query waits to acquire a lock on a table or row. Transaction_timeout (PostgreSQL 17+) limits the total duration of a transaction regardless of individual statement times. When setting timeouts, balance between preventing runaway queries and allowing legitimate long-running operations. For data warehouse workloads, reporting queries, and batch jobs, consider running them against read replicas or using separate connection pools with higher timeouts. Connection pools like pgBouncer can also implement statement-level timeout policies independent of the database server. In containerized environments (Docker, Kubernetes), network latency can cause unexpected timeout behavior—always monitor actual query execution times vs. configured limits.

Frequently asked questions

What does "57014" mean?
Error 57014 (QUERY_CANCELED) is raised when PostgreSQL automatically cancels a query because it exceeded the maximum time allowed to execute. The statement_timeout parameter sets a limit on how long any single SQL statement is allowed to run. When a query surpasses this limit, PostgreSQL terminates it and returns this error to prevent long-running queries from consuming server resources indefinitely.
How do I fix "57014"?
PostgreSQL error 57014 occurs when a query exceeds the configured statement_timeout limit and is automatically terminated. This protects the server from runaway queries. Increase the timeout, optimize the query, or check for locks causing delays.
What causes "57014"?
The statement_timeout value is set too low for the complexity of the query being executed Query is inefficient and taking longer than expected due to missing indexes or poor execution plans Database server is under heavy load or experiencing lock contention, slowing query execution
Is the "57014" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading