Il semble que vous ayez une fuite de connexion dans votre application car elle ne parvient pas à fermer les connexions groupées . Vous ne rencontrez pas de problèmes uniquement avec <idle> in transaction sessions, mais avec trop de connexions globales.
Tuer les connexions n'est pas la bonne réponse à cela, mais c'est une solution de contournement temporaire plutôt correcte.
Plutôt que de redémarrer PostgreSQL pour démarrer toutes les autres connexions à partir d'une base de données PostgreSQL, consultez :Comment puis-je détacher tous les autres utilisateurs d'une base de données postgres ? et Comment supprimer une base de données PostgreSQL s'il y a des connexions actives vers celle-ci ? . Ce dernier affiche une meilleure requête.
Pour définir les délais d'expiration, comme @Doon l'a suggéré, consultez Comment fermer automatiquement les connexions inactives dans PostgreSQL ?, qui vous conseille d'utiliser PgBouncer pour proxy pour PostgreSQL et gérer les connexions inactives. C'est une très bonne idée si vous avez une application boguée qui perd de toute façon des connexions; Je très fortement recommande de configurer PgBouncer.
Un keepalive TCP ne fera pas l'affaire ici, car l'application est toujours connectée et active, elle ne devrait tout simplement pas l'être.
Dans PostgreSQL 9.2 et supérieur, vous pouvez utiliser le nouveau state_change la colonne d'horodatage et l'state champ de pg_stat_activity pour implémenter un faucheur de connexion inactif. Demandez à une tâche cron d'exécuter quelque chose comme ceci :
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'regress'
AND pid <> pg_backend_pid()
AND state = 'idle'
AND state_change < current_timestamp - INTERVAL '5' MINUTE;
Dans les anciennes versions, vous devez implémenter des schémas compliqués qui gardent une trace du moment où la connexion est devenue inactive. Ne pas déranger; utilisez simplement pgbouncer.
