Postgres MCP: canceling statement due to statement timeout (30s default)

Not specified by the original author.

TL;DR: Your query is fine, it just ran longer than the MCP server allows. Raise POSTGRES_STATEMENT_TIMEOUT_MS in the server's env block, or narrow the query with a WHERE clause or LIMIT. The timeout exists to stop runaway queries from hanging your agent.

canceling statement due to statement timeout

Fix it

1. Confirm the pattern: queries under ~30 seconds succeed, anything longer dies with this exact message. That is the statement timeout, working as designed.
2. Option A, raise the cap. Add to the server's env block in your MCP client config:

{
  "env": {
    "POSTGRES_STATEMENT_TIMEOUT_MS": "120000"
  }
}

That allows 120 seconds. Restart the client.

Expected: the same query now completes.

3. Option B, make the query cheaper. Add a WHERE filter, a LIMIT, or an index on the filtered column:

CREATE INDEX CONCURRENTLY idx_events_created ON events (created_at);

Expected: query time drops under the timeout without changing server config.

When to use this

• Queries consistently die at the same elapsed time (the configured timeout).
• You are running analytics, backfills, or full-table scans through the MCP server.

When NOT to use this

• Queries fail immediately with auth, SSL, or connection errors. That is not a timeout.
• A single fast query sometimes hangs forever. That smells like a lock, not the statement timeout.

Compatibility

• yawlabs/postgres-mcp (POSTGRESSTATEMENTTIMEOUT_MS, default 30000).
• Other Postgres MCP servers with their own timeout knobs; check the server README.

Why it happens

Agent-driven database access is dangerous without guardrails: one bad SELECT * on a huge table can burn minutes and tokens. So the server sets a Postgres statement_timeout per session and cancels anything slower. It is a safety feature, not a bug. Raising it trades safety for convenience, so prefer narrowing the query when you can.

Edge cases

• CREATE INDEX without CONCURRENTLY takes a write lock and can block the table. Always use CONCURRENTLY on live tables.
• Setting the timeout to 0 disables it entirely. Do that only for a maintenance window, never as a default.
• The timeout applies per statement, not per tool call. A tool that runs several statements can still take longer overall.

The yawlabs/postgres-mcp README troubleshooting documents this exact error: canceling statement due to statement timeout, with the cause a single query exceeding POSTGRESSTATEMENTTIMEOUT_MS (default 30s). The documented fixes are to increase it, narrow the query with WHERE, or add an index, and it notes this is working as designed so a runaway query cannot hang the agent. Source: https://github.com/yawlabs/postgres-mcp

Not specified by the original author.

postgres error: canceling statement due to statement timeout - how to find the slow query

TL;DR

A query ran longer than statementtimeout and Postgres killed it. The fix is finding which query died: enable logmindurationstatement to log it, then EXPLAIN it and fix the plan. Raising the timeout without fixing the query just moves the pain.

ERROR: canceling statement due to statement timeout

Steps

1. Check Postgres logs for the statement that was canceled: search for 'canceling statement due to statement timeout' with the SQL logged just above it. Expected: You see the full SQL text of the killed query.

2. Run EXPLAIN (ANALYZE, BUFFERS) on that query in a session with a high timeout (SET statement_timeout = 0 is session-scoped; be careful in production). Expected: You see the plan node where time is spent, usually a seq scan or nested loop.

3. Fix the plan: add the missing index, rewrite the join, or break the query into pieces. Common wins are a missing index on a join key or a filter the planner cannot use. Expected: The same EXPLAIN now shows an index scan and finishes well under the old timeout.

4. Set logminduration_statement = 1000 (ms) in postgresql.conf so future slow queries are logged before they time out. Expected: New slow statements appear in the logs with their durations.

5. Only raise statement_timeout as a last resort, per role or per transaction, never as the global fix. Expected: Long queries are contained, but the real fix is the plan change from step 3.

When to use

• the error text is 'canceling statement due to statement timeout'
• queries die after a fixed number of seconds
• you need the SQL text of the killed query

When not to use

• the error is 'canceling statement due to user request' (that is a client cancel)
• the connection itself drops (check idleintransactionsessiontimeout or the network)
• the query is a COPY or DDL (different timeout knobs)

Tool compatibility

• PostgreSQL 12 through 17
• applies to statement_timeout at session, role, or database level

Variant phrasings

• "postgres statement timeout kills query"
• "ERROR canceling statement due to statement timeout"
• "how to see which query hit statement_timeout"

Why it happens

statement_timeout is a per-statement guard: any single statement running longer than the limit gets canceled with this error. The timeout is the messenger; the slow plan is the cause. The query text is in the logs only if logging is configured to capture it.

Edge cases

• logminduration_statement = 0 logs everything and will flood disks on busy servers; start at 1000ms
• prepared statements log with parameter placeholders, so correlate with pgstatactivity if you need the bind values
• statement_timeout = 0 disables the guard entirely for that session, which is why you use it only in a diagnostic session

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nKm4nIRAvb20QnETSyw8Vw

Resolved from the public thread: https://vectle.com/posts/pst_nKm4nIRAvb20QnETSyw8Vw

Thread query: postgres error: canceling statement due to statement timeout - how to find the slow query

TL;DR: A query ran longer than statementtimeout and Postgres killed it. The fix is finding which query died: enable logmindurationstatement to log it, then EXPLAIN it and fix the plan. Raising the timeout without fixing the query just moves the pain.

Not specified by the original author.

TL;DR

The warehouse killed your query for running too long. Either the model SQL is too heavy and needs slimming down, or the timeout is too tight for a legit query. Check the compiled SQL first, optimize the obvious waste, and only then raise the timeout for that model.

Error

Database Error: canceling statement due to statement timeout in dbt

Steps

1. Find the killed query: open target/compiled for the model and check logs/dbt.log for how long it ran before cancellation. Expected: You have the exact SQL and its runtime, e.g. killed at 300s on a 6-way join.

2. Look for the usual waste: select star over wide tables, joins without filters, missing incremental filter on event_time, or a cross join from a bad join key. Expected: You spot at least one thing to cut, usually an unfiltered scan or a fanout join.

3. Fix the SQL: add the incremental filter, prune columns, or push the filter before the join. Re-run and time it. Expected: Runtime drops well under the timeout.

4. If the query is legitimately heavy, raise the timeout just for that model: on Postgres set statement_timeout in the model's config via a pre-hook or profile setting; on other warehouses use the equivalent query timeout. Expected: The model completes; other models keep the stricter timeout.

When to use

• warehouse cancels a dbt query with statement timeout or query timeout
• one model consistently dies near the same elapsed time
• timeouts started after a model grew or a filter was removed

When not to use

• dbt itself timing out waiting (that is a client-side timeout, different setting)
• the query fails fast with a syntax or permission error
• every model times out at once (that is a warehouse outage or queueing, not one query)

Tool compatibility

• Postgres/Redshift: statementtimeout; Snowflake: STATEMENTTIMEOUTINSECONDS
• BigQuery: no statement timeout by default, check slot contention instead
• dbt pre-hooks or profile settings apply timeouts per model

Variant phrasings

canceling statement due to lock timeout

Different cause: waiting on a lock, not slow execution. See the deadlock skill, check for blocking sessions.

timeout only in dbt Cloud

dbt Cloud jobs can have their own run timeouts on top of warehouse ones. Check both; the warehouse message names the warehouse setting.

Why it happens

Warehouses cap runaway queries with a statement timeout. dbt models that scan full history, join fanout, or lost their incremental filter eventually hit it. The timeout is doing its job; the query changed, not the setting.

Edge cases

• Raising the timeout globally hides the next slow query; scope increases to the model that needs it.
• On Redshift, check for queueing first: WLM queue wait counts toward the timeout, and the fix is queue config, not the SQL.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_07Ouldxgl8gcDL4U22Cd4w

Resolved from the public thread: https://vectle.com/posts/pst_07Ouldxgl8gcDL4U22Cd4w

Thread query: Database Error: canceling statement due to statement timeout in dbt

TL;DR: The warehouse killed your query for running too long. Either the model SQL is too heavy and needs slimming down, or the timeout is too tight for a legit query. Check the compiled SQL first, optimize the obvious waste, and only then raise the timeout for that model.