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

簡単な説明

pg_cancel_backend (pid) を使用するとクエリが終了しますが、接続は維持されます。pg_terminate_backend (pid) を使用するとクエリが終了し、接続が閉じます。この関数が完全な接続を終了すると、進行中の他のクエリが影響を受ける可能性があります。pg_terminate_backend(pid) は、必要な場合にのみ使用してください。

これらの関数を使用するには、次のアクセス許可のいずれかが必要です。

• rds_superuser または、デフォルトロール pg_signal_backend のメンバー。
• データベースには、キャンセルするセッションと同じデータベースユーザーで接続します。

注:

• pg_stat_activity ビューの pid 列を参照し、アクティブなバックエンドプロセスのプロセス ID (pid) を特定します。詳細については、PostgreSQL のウェブサイトで pg_stat_activity について参照してください。
• pg_signal_backend は SIGINT シグナルを、pg_terminate_backend は SIGTERM シグナルをバックエンドプロセスに送信します。詳細については、PostgreSQL のウェブサイトで「サーバーシグナリング関数」を参照してください。

解決策

注: 一部の Aurora PostgreSQL 互換バージョンは、すべてのシステム要件が満たされていても autovacuum プロセスを終了できません。これらのバージョンで autovacuum プロセスを終了しようとすると、次のエラーが表示される場合があります。

"ERROR: 42501: スーパーユーザーのプロセスを終了するには、スーパーユーザーである必要があります。LOCATION: pg_terminate_backend, signalfuncs.c:227。」

一部のマイナーバージョンでは、rds_superuser により、ロールに明示的に関連付けられていない autovacuum プロセスを終了させることができます。お使いのバージョンで rds_superuser が autovacuum プロセスを終了できるかどうかを確認するには、「Amazon Aurora PostgreSQL の更新」を参照してください。

pg_cancel_backend(pid) および pg_terminate_backend(pid) 関数の使用方法について、例を次に示します。

pg_cancel_backend(pid):

別のセッションから次の関数を実行すると、pid 8121 のデータベースバックエンドから実行されたクエリがキャンセルされます。

postgres=> SELECT pg_cancel_backend(8121);

期待される出力:

pg_cancel_backend
------------------------
 t
(1 row)

次の内容を実行すると、クエリは正しくキャンセルされ、関数は true (t) を返します。クエリがないか、またはデータベース接続が行われていない場合、関数は false (f) を返します。

pg_terminate_backend(pid):

次のコマンドは、別のセッションから実行すると、pid 8121 のデータベース接続を終了します。

postgres=> SELECT pg_terminate_backend(8121);

期待される出力:

pg_terminate_backend
------------------------
 t
(1 row)

この関数は、プロセスがまだキャンセルされていない場合も true (t) を返します。応答は、SIGTERM シグナルが正常に送信されたことのみを示します。このコマンドは、バックエンドプロセスをすぐには中断しません。共有メモリを一貫性のない状態に保つため、このコマンドは CHECK_FOR_INTERRUPTS の実行中に正常なシャットダウンプロセスを開始します。

終了せず、長時間実行しているプロセスをキャンセルする

割り込み可能なセクションで pg_cancel_backend (pid) と pg_terminate_backend (pid) を実行すると、関数はクエリを正常にキャンセルしません。たとえば、プロセスが軽量ロックまたは、ネットワークストレージデバイスに対する読み取りまたは書き込みシステムコールの取得を待っている場合があります。バックエンドプロセスはシグナルを受けず、無期限に膠着状態になります。

プロセスを終了するには、データベースエンジンを再起動します。

PostgreSQL バージョン 14 以降では、statement_timeout、idle_in_transaction_statement_timeout、idle_session_timeout などのタイムアウトパラメータを調整することがベストプラクティスです。tcp_keepalives_idle、tcp_keepalives_interval、tcp_keepalives_count などのクライアントおよびサーバー側のタイムアウトを設定することもベストプラクティスです。

**statement_timeout ** パラメータは、ステートメント、ユーザーレベル、データベース、インスタンスなどの適切なレベルで設定します。

注: インスタンスレベルまたはデータベースレベルで短いタイムアウトを設定することは、タイムアウトが短い場合、意図的に長時間実行しているクエリもキャンセルされるため、ベストプラクティスではありません。log_min_error_statement が ERROR 以下に設定されている場合、タイムアウトしたステートメントがログに記録されます。詳細については、PostgreSQL のウェブサイトで「ステートメントの動作」を参照してください。

関連情報

Amazon RDS for PostgreSQL または Aurora PostgreSQL DB インスタンスについて、実行中のクエリを確認し、リソース消費の問題を診断する方法を教えてください

Amazon RDS for PostgreSQL または Aurora PostgreSQL 互換 DB インスタンスで、パフォーマンスの問題や実行速度が遅いクエリを特定してトラブルシューティングする方法を教えてください