statement_timeout
Aborts any statement that runs longer than this many milliseconds. A value of zero, the default, disables the timeout entirely.
Defaults and ranges on this page were read from pg_settings on live PostgreSQL 18.4.
What this means
This is a dead-man's switch for a single statement: if a query runs longer than the limit, Postgres cancels it. Zero, the default, means no limit, a runaway query can hold a connection and its locks for as long as it likes. The value is what separates 'one slow query gets cancelled' from 'one slow query takes the whole connection hostage.' Because a legitimately long report would get cancelled too, the usual pattern is a safe ceiling connection-wide, lifted locally for the few operations you know are slow.
When it matters
Set per-session, per-role, or per-transaction (SET LOCAL) wherever a statement should be aborted if it runs unexpectedly long, rather than blocking a connection indefinitely.
| Default | 0 ms |
|---|---|
| Range | 0 – 2147483647 |
| Category | Client connection |
SHOW statement_timeout;Tradeoffs
- • Too low: statements that are legitimately slow (large reports, migrations) get canceled with SQLSTATE 57014 before they can finish.
- • Too high or disabled (the default): a single runaway query can hold resources indefinitely with nothing to stop it.
- • The query-canceled (57014) lab on this platform measured a 2-second query being canceled under a 500ms timeout, and the identical query completing once the timeout was raised to 3s, the GUC's limit is honored almost exactly, not approximately.
Workload profiles
General OLTP
Set a conservative connection-wide value (e.g. a few seconds) as a safety net, and override narrower per known-slow operations.
Prevents one stuck query from holding a connection and its locks indefinitely.
Reporting / batch jobs
Use SET LOCAL statement_timeout inside the specific transaction that needs more time, rather than raising it globally.
Tested in the query-canceled (57014) lab: repeatedly retrying the identical query under an unchanged timeout never succeeds, only raising the timeout (or fixing the query) does.