statement timeoutの直し方｜PostgreSQL

ERROR: canceling statement due to statement timeout は、1つの SQL の実行時間が、statement_timeout の設定を超えたので、PostgreSQL が SQL を取り消したときのエラーです。 SQLSTATE は 57014 です。

直す前に、次の2つを確かめます。

タイムアウトの値を延ばすのは、最後の手段です。ロック待ちが原因なら、延ばしても待つ時間が長くなるだけです。

確認環境：PostgreSQL 16.15、psycopg 3.3.6 で再現しました（確認日 2026年10月11日）。

再現

SHOW statement_timeout;     -- 2s
SELECT pg_sleep(3);

ERROR:  57014: canceling statement due to statement timeout

Python（psycopg 3）では、psycopg.errors.QueryCanceled（sqlstate 57014）として受け取れました。公式ドキュメントによると、statement_timeout は単位を書かなければミリ秒で、0（既定）なら無効です。

① 設定がどこで決まっているかを探す

「設定した覚えがないのにタイムアウトする」ときは、pg_settings の source 列を見ます。

SELECT name, setting, unit, source FROM pg_settings
WHERE name IN ('statement_timeout', 'lock_timeout', 'idle_in_transaction_session_timeout');

ロールと DB の両方に設定したときは、ロールの設定（2s）が使われ、source は user でした。 ロール・DB に付けた設定の一覧は、次の SQL で見られます。

SELECT r.rolname, d.datname, s.setconfig
FROM pg_db_role_setting s
LEFT JOIN pg_roles r ON r.oid = s.setrole
LEFT JOIN pg_database d ON d.oid = s.setdatabase;

 rolname | datname |       setconfig
---------+---------+------------------------
 tx      |         | {statement_timeout=2s}

公式ドキュメントでは、statement_timeout を postgresql.conf に書くことは、すべてのセッションに影響するため推奨しないとされています。アプリのフレームワーク・接続プールの設定（接続文字列の options など）で付いていることもあるので、client と表示されたらアプリの設定を探します。

② 遅い SQL か、ロック待ちかを見分ける

別の接続で行を UPDATE したまま（トランザクションを閉じずに）、同じ行を UPDATE しました。

ERROR:  57014: canceling statement due to statement timeout
CONTEXT:  while updating tuple (0,6) in relation "st_acc"

CONTEXT: while updating tuple ... in relation "st_acc" が付いていたら、行のロックを待っている間にタイムアウトしたと読めます。pg_sleep だけの遅い SQL では、CONTEXT は付きませんでした。

止めている相手を pg_stat_activity で探す

SELECT pid, application_name AS app, state, wait_event_type AS wtype, wait_event,
       pg_blocking_pids(pid) AS blocked_by, left(query, 40) AS query
FROM pg_stat_activity
WHERE datname = 'reldemo' AND pid <> pg_backend_pid();

 pid  |   app   | state  |  wtype  |  wait_event   | blocked_by
------+---------+--------+---------+---------------+------------
 1841 | batch_a | active | Timeout | PgSleep       | {}
 1845 | web_b   | active | Lock    | transactionid | {1841}

ロック待ちが原因なら、直すのは止めている側（batch_a）です。長いトランザクションを短くする、ロックを取る順番をそろえる、などを検討します。application_name を接続ごとに付けておくと、どのプログラムかが分かります。

lock_timeout との違い

lock_timeout = '1s' を付けて、同じロック待ちを起こしました。

ERROR:  55P03: canceling statement due to lock timeout
CONTEXT:  while updating tuple (0,6) in relation "st_acc"

公式ドキュメントでは、statement_timeout が 0 でないとき、lock_timeout を同じか大きい値にしても意味がない（先に statement_timeout が来るため）と説明されています。lock_timeout を短め、statement_timeout を長めにすると、エラーの種類で原因を見分けられます。

idle_in_transaction_session_timeout は、トランザクションを開いたまま放置する接続を切ります。 公式ドキュメントでも、ロックを長く持ち続けるのを防ぐ用途が挙げられています。上の batch_a のような接続への対策になります。

一部の処理だけ、タイムアウトを延ばす（SET LOCAL）

夜間の集計だけ長くしたい、といった場合は、トランザクションの中で SET LOCAL を使います。

BEGIN;
SET LOCAL statement_timeout = '30min';     -- このトランザクションの中だけ
-- 時間のかかる集計
COMMIT;
SHOW statement_timeout;                    -- 元の値に戻っている

SET（LOCAL なし）は、その接続を使い続ける限り残ります。 接続プールでは、次にその接続を使う別の処理にも影響するので、SET LOCAL を使います。

遅い SQL を速くする

ロック待ちでなかった場合は、SQL そのものを見直します。

確認の手順（チェックリスト）

よくある質問

Q. デッドロックのエラーとは違いますか。 A. 違います。デッドロックは、お互いが相手を待つ状態を PostgreSQL が見つけて、片方を止めるエラーです。タイムアウトは、待つ時間（実行時間）が設定を超えたときのエラーです。MySQL のデッドロックは、関連記事の「MySQL Deadlock foundの原因と対処｜1213・1205」で扱っています。

まとめ

• SQL の実行時間が statement_timeout を超えたエラー（57014）
• pg_settings の source で、ロール・DB・接続・SQL のどこで設定されたかが分かる
• CONTEXT: while updating tuple はロック待ち。pg_blocking_pids で止めている相手を探す
• lock_timeout（55P03）を短めにすると、原因を見分けやすい
• 延ばすなら SET LOCAL（トランザクションの外では効かない）

参考・出典

確認日はいずれも 2026年10月11日です。

• PostgreSQL 16 文書「Client Connection Defaults」（statement_timeout・lock_timeout）：https://www.postgresql.org/docs/16/runtime-config-client.html
• PostgreSQL 16 文書「SET」：https://www.postgresql.org/docs/16/sql-set.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。