Data Query Timeouts and Cancellation Controls

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

Timeouts and cancellation controls help data agents stop runaway queries, but they need query IDs, permissions, and transaction context before acting.

## Core Explanation

Long-running queries can consume warehouse capacity, block locks, delay pipelines, or surprise a team with cost. Agents need to know how to inspect and stop a query without guessing from a console message.

Useful evidence includes query ID, user or role, warehouse or database, statement text, start time, wait event, lock state, estimated cost, destination table, transaction state, client timeout, server timeout, and cancellation permission. A timeout configured on the client is different from a server-side statement limit, and canceling a query is different from terminating a session.

Agents should prefer read-only diagnosis before cancellation. When a query is destructive, transactional, or part of a pipeline, cancellation should require explicit owner or operator review.

## Source-Mapped Facts

- PostgreSQL documentation describes statement_timeout as a setting that aborts statements running longer than the configured duration. ([source](https://www.postgresql.org/docs/current/runtime-config-client.html))
- Snowflake documentation describes SYSTEM$CANCEL_QUERY as a function for canceling a running query by query ID. ([source](https://docs.snowflake.com/en/sql-reference/functions/system_cancel_query))
- BigQuery REST documentation defines a jobs.cancel method for canceling a specified job. ([source](https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs/cancel))

## Further Reading

- [PostgreSQL statement_timeout](https://www.postgresql.org/docs/current/runtime-config-client.html)
- [Snowflake SYSTEM$CANCEL_QUERY](https://docs.snowflake.com/en/sql-reference/functions/system_cancel_query)
- [BigQuery jobs.cancel](https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs/cancel)