pg_stat_activityに「idle」状態の長期的な「COMMIT」クエリ
クエリした場合：
select * from pg_stat_activity where application_name ~ 'example-application';
状態がidleで、クエリがCOMMITである行を多数取得します。それらは長持ちし、消えることはありません。しばらくすると、アプリケーションがhibernate.c3p0.max_size（プール内のJDBC接続の最大数）の制限に達し、データベースでの作業を停止します。
一部のアプリケーション実装の詳細は、他のSOスレッド： スレッドプール内のGuice DAOプロバイダー-クエリは「変換中のアイドル」になります
なぜそれが起こるのですか？この問題を解決する方法は？
セッションが「アイドル」の場合、クエリ列には、接続が実行されたlastステートメントが表示されます。これはnot「現在の」クエリであるため、接続はnotコミットの終了を待機しています。
query列に表示されるのはcurrentステートメントのみです（statusにactiveが表示される場合）。
「アイドル」接続は問題ではありませんであり、本質的に接続プールが使用される理由であり、再利用できます。ただし、「トランザクションのアイドル状態」で非常に長くとどまるセッションare問題。しかし、あなたはあなたの接続が「アイドル」状態にあると述べました。
接続プールが制限に達した場合、これはおそらく、アプリケーションが接続をプールに適切に返さないことを意味します。これは、アプリケーションで修正する必要があるものです。