Aurora PostgreSQL 互換データベースクラスターで実行されるクエリの "Statement timeout" エラーをトラブルシューティングする方法を教えてください。

解決策

重要: 2026 年 6 月 30 日に Performance Insights のサポートは終了します。2026 年 6 月 30 日までに、Database Insights のアドバンストモードにアップグレードしてください。アップグレードしない場合、Performance Insights を使用する DB クラスターは、デフォルトで Database Insights のスタンダードモードを使用します。実行計画とオンデマンド分析は、Database Insights のアドバンストモードでのみサポートされます。クラスターがデフォルト設定によりスタンダードモードになった場合、コンソールでこれらの機能を使用できない可能性があります。Advanced モードの有効化については、「Amazon RDS で Database Insights のアドバンストモードを有効にする」および「Amazon Aurora で Database Insights のアドバンストモードを有効にする」を参照してください。

statement_timeout パラメータで指定された時間内にクエリを実行できない場合、statement_timeout パラメータはクエリをキャンセルします。次のエラーメッセージが表示されます。

"ERROR: canceling statement due to statement timeout."

このエラーをトラブルシューティングするには、次の操作を実行します。

設定されている statement_timeout パラメータを確認する

DB クラスターパラメータグループまたは DB パラメータグループの statement_timeout パラメータを確認するには、次の SELECT クエリを実行します。

SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'statement_timeout';

想定される出力:

       name        | setting | unit | context |       source
-------------------+---------+------+---------+--------------------
 statement_timeout | 5000    | ms   | user    | configuration file

注: 出力例では、statement_timeout パラメータの値は 5000 ミリ秒です。"source" フィールドには "configuration file" が表示されます。これは、パラメータがクラスターパラメータグループレベルで設定されていることを示します。

次に、ロールレベルとデータベースレベルで statement_timeout パラメータを確認します。

データベースクラスター内のすべてのロールのロールレベル設定を確認するには、次のクエリを実行します。

SELECT r.rolname, d.datname, s.setconfig
FROM pg_db_role_setting s
JOIN pg_roles r ON r.oid = s.setrole
LEFT JOIN pg_database d ON d.oid = s.setdatabase
WHERE s.setconfig::text LIKE '%statement_timeout%'
ORDER BY r.rolname;

クラスター内のすべてのデータベースのデータベースレベル設定を確認するには、次のクエリを実行します。

SELECT d.datname, rs.setconfig
FROM pg_db_role_setting rs
JOIN pg_database d ON d.oid = rs.setdatabase
WHERE rs.setrole = 0;

出力を確認して、クラスターレベルの設定をオーバーライドしている可能性のある、ロールレベルまたはデータベースレベルで設定されている statement_timeout 設定を特定します。

注: ALTER ROLE SET で設定した statement_timeout パラメータは、子ロールに継承されません。statement_timeout パラメータをロールに設定した場合、そのロールにログインするときにのみパラメータを使用できます。詳細については、PostgreSQL のウェブサイトで「ALTER ROLE」を参照してください。

キャンセルされた SQL クエリを特定する

PostgreSQL エラーログファイルを表示し、log_min_error_statement パラメータが ERROR、またはそれより低い重要度に設定されているかを確認します。失敗したステートメントを特定したら、失敗した SQL とテーブル名を探します。詳細については、「log_line_prefix パラメータの概要」を参照してください。

クエリの実行時間が長くなる原因を特定する

失敗した SQL クエリが見つかった場合は、CloudWatch Database Insights を使用して、ブロックされたトランザクションを特定します。

CloudWatch Database Insights を使用してパフォーマンスを分析するには、次の手順を実行します。

1. Amazon Relational Database Service (Amazon RDS) コンソールを開きます。
2. ナビゲーションペインで [データベース] を選択します。
3. 対象の Aurora PostgreSQL DB クラスターを選択します。
4. [モニタリング] タブに切り替えます。
5. Performance Insights の [詳細を表示] を選択します。
6. DB の負荷を確認します。DB の負荷を待機イベント、SQL クエリ、ホスト、またはユーザーごとにグループ化して、ブロックされたトランザクションを識別できます。

問題が繰り返し発生する場合は、DB インスタンスの log_min_duration_statement パラメータを設定し、auto_explain モジュールを使用してください。詳細については、「Amazon RDS PostgreSQL または Aurora PostgreSQL のクエリの実行プランをログ記録して、クエリのパフォーマンスを調整する方法を教えてください」を参照してください。

EXPLAIN コマンドと EXPLAIN ANALYZE コマンドを使用して、クエリ実行プランを取得できます。詳細については、「Amazon RDS for PostgreSQL または Aurora PostgreSQL 互換 DB インスタンスで、パフォーマンスの問題や実行速度が遅いクエリを特定してトラブルシューティングする方法を教えてください」を参照してください。

ソーステーブルのデッド行を確認する

デッド行またはタプルは SELECT 時間を延ばす可能性があります。ソーステーブルに多数のデッド行がないかチェックするには、次のクエリを実行します。

SELECT * FROM pg_stat_user_tables WHERE relname = 'table_name';

注: table_name を実際のソーステーブル名に置き換えてください。

関連情報

Amazon RDS for PostgreSQL または Aurora PostgreSQL 互換 DB インスタンスで、長時間実行しているクエリを終了させる方法を教えてください

Amazon RDS PostgreSQL または Aurora PostgreSQL データベースインスタンスでクエリがブロックされている原因を特定する方法を教えてください