アプリケーション(クライアント側)で接続とコマンドのタイムアウトを10分に設定しました。
アプリケーションが単純なクエリを実行するよりも:SELECT pg_sleep(65)
一部のサーバーでは正常に動作しますが、他のサーバーは60秒後に接続を閉じます。
これは、タイムアウトを制限し、クライアント設定を無視するある種のPostgreSQLサーバー構成になる可能性がありますか?
ドキュメントに記載されている2つの設定 (idle_in_transaction_session_timeout
はバージョン9.6xの新機能です)
statement_timeout
(整数)コマンドがクライアントからサーバーに到着したときから、指定されたミリ秒を超えるステートメントをすべて中止します。 log_min_error_statementがERROR以下に設定されている場合、タイムアウトしたステートメントもログに記録されます。値ゼロ(デフォルト)はこれをオフにします。
Postgresql.confでstatement_timeoutを設定すると、すべてのセッションに影響するため、お勧めできません。
idle_in_transaction_session_timeout
(整数)ミリ秒単位の指定された期間よりも長い間アイドル状態になっている開いているトランザクションを持つセッションを終了します。これにより、そのセッションで保持されているロックを解放し、接続スロットを再利用できます。また、このトランザクションにのみ表示されるタプルをバキュームすることもできます。この詳細については、セクション24.1を参照してください。
デフォルト値の0は、この機能を無効にします。
アミューズメントが必要でない限り、postgresql.confでstatement_timeout
を設定しないことが重要です。
これが機能する例です
SET statement_timeout = 10000;
SET
test=# SELECT pg_sleep(15);
ERROR: canceling statement due to statement timeout
箱から出していない。ただし、設定を無視するカスタムサーバーをコンパイルするのは非常に簡単です。
しかし、はるかに可能性が高いのは、接続がアイドル接続を好まないファイアウォールまたはゲートウェイによって切断されていることです。
サーバーのログファイルにアクセスできる場合は、それが手掛かりになるはずです。クライアントがサーバーが予期せず接続を閉じたと言い、サーバーがクライアントが予期せず接続を閉じたと言った場合、それはおそらくクライアントとサーバーの間で実際に接続を切断していることです。