PostgreSQL: server closed the connection unexpectedly

SQLSTATE 08006 (connection_failure) · Aktualisiert 9. Juli 2026

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

Die TCP-Verbindung endete ohne einen ordentlichen Protokoll-Abschied. Zwei sehr unterschiedliche Ursachenfamilien erzeugen diese identische Client-Meldung: etwas hat die Serverseite getötet (Absturz, Neustart, Out-of-Memory), oder eine Netzwerk-Middlebox hat stillschweigend eine Idle-Verbindung verworfen. Eine Prüfung trennt sie: das Server-Log zu diesem Zeitpunkt.

Was dieser Fehler bedeutet

Lesen Sie das Server-Log für den Moment der Trennung:

• server process (PID ...) was terminated by signal 9: Killed → der Linux-OOM-Killer hat ein Backend erschossen (bestätigen Sie in dmesg). PostgreSQL startet dann neu und trennt kurz alle.
• terminating connection due to administrator command → jemand (oder systemd oder ein Failover) hat die Dinge absichtlich gestoppt.
• Crash-Restart-Zeilen (all server processes terminated; reinitializing) → ein Backend ist abgestürzt; schauen Sie direkt darüber nach dem Grund.
• Gar nichts im Log → der Server wusste nie davon: ein NAT-Gateway, ein Load Balancer oder eine Firewall hat den Idle-Flow verworfen. Load-Balancer-Idle-Timeouts von einigen Minuten sind typische Übeltäter.

Häufige Ursachen

• OOM-Kills — oft durch Speichereinstellungen getrieben: work_mem gilt pro Sort-/Hash-Knoten pro Query, sodass ein paar speicherhungrige Queries über viele Verbindungen weit über das physische RAM hinaus multiplizieren können.
• Neustarts und Failover (geplant oder nicht) mitten in einer Verbindung.
• Idle-Verbindungen von Middleboxes gekappt, die sich bei der nächsten Nutzung einer gepoolten Verbindung als dieser Fehler zeigen.
• Gelegentlich ein echter Server-Bug, der ein Backend bei einer bestimmten Query zum Absturz bringt — prüfen Sie das Log und die Release Notes für Ihre Minor-Version.

So diagnostizieren Sie ihn

• Server-Log zum Zeitpunkt — entscheidet zwischen den Familien, wie oben.
• OOM vermutet: dmesg | grep -i oom und überprüfen Sie die Speichereinstellungen gegen das verfügbare RAM.
• Log schweigt: messen Sie, wie lange die Verbindung vor dem Fehlschlag idle war; vergleichen Sie mit LB-/NAT-Idle-Timeouts im Pfad.

So beheben Sie ihn

• OOM → dimensionieren Sie den Speicher richtig (work_mem besonders, angesichts seiner multiplikativen Natur), begrenzen Sie die Verbindungsanzahl mit einem Pooler und folgen Sie der Anleitung der Dokumentation zu Linux Memory Overcommit für dedizierte Datenbank-Hosts.
• Middlebox → aktivieren Sie TCP-Keepalives aggressiver als das Idle-Timeout (Server: tcp_keepalives_idle; Client: keepalives_idle im Connection-String) und/oder setzen Sie die maximale Verbindungslebensdauer des Pools unter das Middlebox-Timeout.
• Abstürze → aktualisieren Sie auf die neueste Minor-Version; wenn auf aktuellen Versionen reproduzierbar, ist das ein Bug-Report.