実行時間の長いPostgresクエリがあり、通常の "kill [pid]"が機能せず、pg_cancel_backendが機能しない場合、どうすればよいですか?
http://www.postgresql.org/docs/current/static/server-shutdown.html
pg_cancel_backendは、SIGINTをプロセスに送信することと同じです。
SIGTERMの場合と同様にpg_terminate_backendですが、pg_cancel_backendが機能していない場合、pg_terminate_backendが機能する理由がわかりません。
これらのオプションを試した場合は、SIGQUITを試すことができます。ドキュメントは、「これは緊急時にのみ推奨されます。」と言います
(もしあなたのデータが嫌いで、それが死ぬことを望むなら、SIGKILLを使うことができます。しかし私はしません。)
kill
を直接使用することも、pg_ctl kill
。
サーバー全体を強制的に停止することが目的でない限り、never kill -9を実行してください。シェルからのpg_cancel_backend()呼び出しに応答しないプロセスを強制終了できます
kill <pid>
つまり、-9ではありません。ネットワーク接続上のデータをループで待機しているプロセスがハングしているために、それでも機能しない場合が何度かありました。正しく思い出せば、クライアントプロセスを強制終了することで対処できます。
最近のPostgresを使用している場合は、pg_terminate_backend
代わりに。
bribles は上記の彼のステートメントでは正しいです...
[〜#〜] if [〜#〜]あなたは私のためにサーバーをSHUTDOWN
しようとしています:
私は引退したデータベース/スキーマを削除しようとしていますが、それでもまだ手放せない長引く接続があります。
だから、あなたの質問に答えるために、
長時間実行するPostgresクエリがある場合...
pg_cancel_backendが機能しません...
私は何をすべきか?
NOT RELATEDサーバーをシャットダウンする方法はありません。
このpg_cancel_backend()
の動作が機能しないことも確認しました。そして、私の実用的なソリューションを共有したかったのです。
これまでのところ、データの「損失」のような問題は見ていません。
ここでも、Active
クエリを強制終了しようとしているわけではありません。
-私は777777のセッションまたはPIDでUSER "A"としてログインしています。
-そして、123456789として開いているユーザー "A"から別のセッションを強制的に切断しようとします
-これはスリープ状態の接続であり、以下のクエリで
idle
も検索する理由です。
SELECT *
FROM pg_stat_activity
WHERE pid = 123456789
AND STATE = 'idle';
-試行1
SELECT pg_cancel_backend(pid)
FROM pg_stat_activity
WHERE pid = 123456789
AND STATE = 'idle';
-興味深いことに、結果には、キャンセルはTRUEであるが、まだ存在していることが示されています。
SELECT *
FROM pg_stat_activity
WHERE pid = 123456789
AND STATE = 'idle';
-試行2
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE pid = 123456789
AND STATE = 'idle';
-そして、それは存在しません。
SELECT *
FROM pg_stat_activity
WHERE pid = 123456789
AND STATE = 'idle';
-注:私はとんでもないpid#を使用して、人々が自分の人生をコピーして貼り付けたり破壊したりするのを防ぐのに役立てようとしました。
-注:デフォルトでは、postgresは、ユーザーのログインの下で実行されているプロセスのみを強制終了できます。
-注:しかし、あなたはすでにそれを知っていました。
お役に立てれば。 =)
〜ジェイ