pg_cancel_backendが機能しない場合はどうすればよいですか？

実行時間の長いPostgresクエリがあり、通常の "kill [pid]"が機能せず、pg_cancel_backendが機能しない場合、どうすればよいですか？

サーバー全体を強制的に停止することが目的でない限り、postgresプロセスを強制終了することはできません。シェルからpg_cancel_backend（）呼び出しに応答しないプロセスを強制終了できます

kill <pid>

つまり、-9ではありません。ネットワーク接続上のデータをループで待機しているプロセスがハングしているために、それでも機能しない場合が何度かありました。私が正しく思い出せば、クライアントプロセスを強制終了することで対処できました。

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。

最近のPostgresがある場合は、pg_terminate_backend代わりに試すことができます。

briblesは上記の彼の声明で正しいです...

IFあなたがしようとしているSHUTDOWNのに、私のために、サーバー：

私は引退したデータベース/スキーマを削除しようとしていますが、それでもまだ手放せない長引く接続があります。

だから、あなたの質問に答えるために、

実行時間の長いPostgresクエリがある場合...

pg_cancel_backendが機能しません...

私は何をすべきか？

何らかの方法でサーバーをシャットダウンすることとは関係ありません。

私もこの動作しpg_cancel_backend()ない動作を見ました。そして、私の実用的なソリューションを共有したかった。

これまでのところ、データの「損失」のような問題は見ていません。

繰り返しますが、私はActiveクエリを殺そうとしているわけでもありません。

-私は777777のセッションまたはPIDでUSER "A"としてログインしています。

-そして、「456456789」として開いているユーザー「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は、ログインしているユーザーの下で実行されているプロセスのみを殺すことができます。

-注：しかし、あなたはすでにそれを知っていました。

お役に立てれば。=）

〜ジェイ