PostgreSQL : server closed the connection unexpectedly

SQLSTATE 08006 (connection_failure) · Mis à jour 9 juillet 2026

server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

La connexion TCP s'est terminée sans un vrai au revoir protocolaire. Deux familles de causes très différentes produisent ce message client identique : quelque chose a tué le côté serveur (plantage, redémarrage, manque de mémoire), ou un middlebox réseau a silencieusement lâché une connexion inactive. Une seule vérification les sépare : le journal du serveur à cet horodatage.

Ce que signifie cette erreur

Lisez le journal du serveur au moment de la déconnexion :

• server process (PID ...) was terminated by signal 9: Killed → l'OOM killer de Linux a abattu un backend (confirmez dans dmesg). PostgreSQL redémarre alors et déconnecte brièvement tout le monde.
• terminating connection due to administrator command → quelqu'un (ou systemd, ou une bascule) a intentionnellement arrêté les choses.
• Lignes de plantage-redémarrage (all server processes terminated; reinitializing) → un backend a planté ; regardez juste au-dessus pour la raison.
• Rien du tout dans le journal → le serveur n'a jamais su : une passerelle NAT, un load balancer ou un pare-feu a lâché le flux inactif. Les timeouts d'inactivité de quelques minutes des load balancers sont des coupables typiques.

Causes fréquentes

• Kills OOM — souvent dus aux réglages mémoire : work_mem s'applique par nœud de tri/hachage par requête, donc quelques requêtes gourmandes en mémoire réparties sur de nombreuses connexions peuvent se multiplier bien au-delà de la RAM physique.
• Redémarrages et bascules (planifiés ou non) en pleine connexion.
• Connexions inactives coupées par des middleboxes, se manifestant par cette erreur à la prochaine utilisation d'une connexion poolée.
• Occasionnellement, un véritable bug serveur plantant un backend sur une requête spécifique — vérifiez le journal et les notes de version de votre version mineure.

Comment la diagnostiquer

• Journal du serveur à l'horodatage — tranche entre les familles, comme ci-dessus.
• OOM suspecté : dmesg | grep -i oom et revoyez les réglages mémoire par rapport à la RAM disponible.
• Journal muet : mesurez depuis combien de temps la connexion était inactive avant d'échouer ; comparez aux timeouts d'inactivité LB/NAT sur le chemin.

Comment la corriger

• OOM → dimensionnez correctement la mémoire (work_mem surtout, vu sa nature multiplicative), bornez le nombre de connexions avec un pooler, et suivez les recommandations de la documentation sur l'overcommit mémoire Linux pour les hôtes de base de données dédiés.
• Middlebox → activez des keepalives TCP plus agressifs que le timeout d'inactivité (serveur : tcp_keepalives_idle ; client : keepalives_idle dans la chaîne de connexion) et/ou fixez la durée de vie maximale des connexions du pool en dessous du timeout du middlebox.
• Plantages → mettez à jour vers la dernière version mineure ; si c'est reproductible sur les versions actuelles, c'est un rapport de bug.