08006ERRORTier 2 — Caution⚠️ MEDIUM confidence

connection failure

Category: Connection ExceptionVersions: All Postgres versions

What this means

An established connection to the Postgres server was lost unexpectedly during a session. The error is raised on the client side when the network socket is closed or reset before the server finished sending a response.

Why it happens

1Network interruption between client and server (firewall rule, NAT timeout, VPC issue)
2Postgres server process (postmaster or backend) crashed or was killed by the OOM killer
3Server-side idle_in_transaction_session_timeout or statement_timeout terminated the backend
4Connection pool proxy (pgBouncer, RDS Proxy) closed an idle connection
5SSL renegotiation failure or certificate mismatch

How to reproduce

A long-running query is interrupted by a network drop or server-side timeout.

trigger — this will ERROR

-- Simulate by terminating the backend from another session:
SELECT pg_terminate_backend(pg_backend_pid());
-- The victim session receives 08006

FATAL: terminating connection due to administrator command server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request.

Fix 1: Implement connection retry with exponential backoff

When transient network issues are the cause and the operation is idempotent.

fix

-- Liveness probe before executing:
SELECT 1;

-- Reconnect and retry in application code on SQLSTATE 08006.
-- Use connection pool max_retries and reconnect_on_failure settings.

Why this works

Postgres backend processes are independent OS processes. When a backend crashes or the network drops, the client socket receives EOF or RST. The client driver raises 08006. Reconnecting creates a fresh backend process via the postmaster fork pathway.

Fix 2: Tune keepalive and timeout settings

When idle connections are being dropped by NAT/firewalls or proxy timeouts.

fix

-- Set server-side idle timeout (Postgres 9.6+):
ALTER SYSTEM SET idle_in_transaction_session_timeout = '5min';
SELECT pg_reload_conf();

-- Connection string keepalive params:
-- keepalives=1&keepalives_idle=60&keepalives_interval=10&keepalives_count=5

Why this works

TCP keepalive probes prevent NAT tables and firewalls from expiring idle connections. idle_in_transaction_session_timeout terminates backends stuck in a transaction, freeing locks; the client receives 08006 and knows to reconnect.

What not to do

✗

Disable SSL to work around SSL-related 08006 errors

Why it's wrong: Exposes credentials and data in transit to eavesdropping; fix the certificate issue instead.

Version notes

Postgres 9.6+idle_in_transaction_session_timeout parameter added; previously only statement_timeout was available.

Dangerous variant

⚠️ Warning

If the connection drops mid-transaction, the transaction is automatically rolled back by the server. Retrying without checking transaction state can cause double-execution of non-idempotent operations.

Sources

📚 Official docs: https://www.postgresql.org/docs/current/errcodes-appendix.html

📚 Feature docs: https://www.postgresql.org/docs/current/runtime-config-connection.html

📖 Further reading: Client Connection Defaults

Confidence assessment

⚠️ MEDIUM confidence

The error code is stable but causes are highly environment-dependent (network, OS, proxy). The keepalive and timeout recommendations are well-established. Edge cases around SSL renegotiation behaviour vary by libpq version and OpenSSL version.