Cette erreur signifie que PostgreSQL n’a plus de place pour une nouvelle connexion ordinaire. Certaines places peuvent être réservées à des rôles privilégiés : le nombre visible peut donc être inférieur à max_connections au moment où votre application est refusée.
Confirmer la limite et l’ampleur
Connectez-vous avec une session déjà ouverte ou un compte autorisé à accéder aux connexions réservées. Si aucune connexion n’est possible, utilisez le tableau de bord ou les journaux de votre hébergement pour obtenir un premier diagnostic. N’arrêtez pas le serveur simplement pour libérer des places.
Dans psql :
SHOW max_connections;
SHOW superuser_reserved_connections;
SELECT count(*) AS connexions FROM pg_stat_activity;Sur les versions qui disposent de reserved_connections, vérifiez aussi ce paramètre. Les droits du compte influencent les détails visibles sur les autres sessions ; pg_stat_activity peut masquer certaines informations.
Trouver d’où viennent les connexions
SELECT datname, usename, application_name, client_addr, state,
count(*) AS connexions
FROM pg_stat_activity
GROUP BY datname, usename, application_name, client_addr, state
ORDER BY connexions DESC;Regardez si les sessions viennent d’une seule application, de plusieurs instances ou de tâches planifiées. Une forte proportion de sessions idle peut indiquer un pool trop grand ou plusieurs pools cumulés ; idle in transaction appelle une enquête sur les transactions laissées ouvertes.
| Observation | Piste à vérifier |
|---|---|
| Beaucoup de connexions du même service | Taille du pool multipliée par le nombre d’instances |
| Connexions qui augmentent sans redescendre | Connexions ou clients non libérés |
Sessions idle in transaction |
Transaction non terminée ; peut aussi retenir des verrous |
| Pic après déploiement | Anciennes et nouvelles instances actives simultanément |
Pour mesurer les durées des transactions ouvertes :
SELECT pid, application_name, state,
clock_timestamp() - xact_start AS duree_transaction
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;Corriger du côté de l’application
Calculez le maximum potentiel : taille du pool par instance × nombre d’instances, puis ajoutez les outils d’administration, migrations et autres services. Gardez une marge sous la limite du serveur. Réutilisez un pool plutôt que d’en créer un à chaque requête ; rendez les connexions empruntées dans un bloc de nettoyage, même en cas d’erreur. Fermez les pools lors de l’arrêt propre de l’application.
Pour les tâches courtes, évitez qu’un pool différent soit créé à chaque exécution sans être fermé. Si le nombre d’instances est élevé, envisagez un pooler tel que PgBouncer après avoir vérifié sa compatibilité avec votre mode de transactions et votre application.
Augmenter max_connections en premier peut déplacer le problème. Chaque connexion consomme des ressources serveur, et une hausse de la limite ne répare pas une fuite ou une multiplication incontrôlée des pools.
Libérer une session seulement en dernier recours
Si une session bloquée a été identifiée avec certitude, examinez sa transaction et son propriétaire. pg_cancel_backend(pid) demande l’arrêt de sa requête courante ; pg_terminate_backend(pid) ferme la session et annule sa transaction ouverte. Les deux demandent des droits adaptés et peuvent interrompre un travail utile.
SELECT pg_cancel_backend(PID_CIBLE);Remplacez PID_CIBLE par un PID vérifié dans pg_stat_activity, puis mesurez de nouveau. Ne terminez pas des sessions au hasard : l’application peut les rouvrir immédiatement et amplifier l’incident.
Vérifier la résolution
Après la correction, observez les connexions pendant une charge normale et lors d’un déploiement. Vérifiez que leur nombre revient à un niveau stable, que les erreurs cessent et que les requêtes ne sont pas simplement mises en attente trop longtemps dans le pool applicatif.