PostgreSQL Error 08006: Connection Failure

PostgreSQL SQLSTATE 08006 is connection_failure. It means the client could not maintain or complete the database connection; the code alone does not identify whether the cause was a server restart, network interruption, proxy timeout, or another communications failure. PostgreSQL lists 08006 in its error-code appendix.

Check whether PostgreSQL is reachable now

Run pg_isready against the same host and port used by the application:

pg_isready -h db.example.com -p 5432

Exit status 0 means the server is accepting connections, 1 means it is rejecting them, 2 means no response was received, and 3 means no attempt was made (for example, because a parameter was invalid). pg_isready reports server readiness; it does not verify that a particular username, password, or database can log in. PostgreSQL may log a failed connection attempt if you supply incorrect values. This check cannot explain an earlier disconnect. See PostgreSQL Error 57P03 for startup and recovery refusals and the official pg_isready documentation.

If the server is reachable now, compare the application’s error time with PostgreSQL logs, managed-service events, deployment or failover events, and network proxy logs. A client-side Connection reset or timeout can happen without a PostgreSQL error response. Check application_name and the request or job ID so logs from the same connection attempt can be correlated.

Check network idle limits and TCP keepalives

Intermittent disconnects during idle periods may come from a firewall, NAT gateway, load balancer, or proxy that closes inactive TCP connections. Compare its idle timeout with the client’s and server’s keepalive settings. PostgreSQL exposes server-side values such as:

SHOW tcp_keepalives_idle;
SHOW tcp_keepalives_interval;
SHOW tcp_keepalives_count;
SHOW tcp_user_timeout;

Zero generally selects the operating system default for these settings, and support varies by platform. Client-side libpq options have corresponding keepalive controls. See PostgreSQL’s server TCP settings and libpq connection parameters.

Do not change keepalive values blindly: first identify which network hop is closing the connection and whether the disconnect affects idle or active sessions.

Reconcile writes before retrying

If a connection drops during a read, the client may be able to retry it according to the application’s policy. If it drops while a write or COMMIT is in progress, the client may not know whether the server committed the transaction before the response was lost. PostgreSQL defines SQLSTATE 08007 (transaction_resolution_unknown) for an unknown transaction outcome, but applications can also see a generic connection failure.

Before retrying a write, check its result using an application-level idempotency key or another safe reconciliation query. A blind retry can duplicate payments, orders, or other side effects. Keep network calls and external side effects outside database transactions when possible.

Distinguish related connection failures

• Error 57P03 (cannot_connect_now): PostgreSQL reports that it is temporarily not accepting this connection, commonly during startup or recovery. See Error 57P03.
• Error 57P01 (admin_shutdown): the server explicitly terminated the connection because of an administrative shutdown request; see Error 57P01.
• Error 53300 (too_many_connections): the server has no client connection slot available. See Error 53300.
• Error 28P01 (invalid_password): the server rejected password authentication. See Error 28P01.

If the query was canceled instead

If a client or administrator deliberately cancels a running query and the server processes the cancel request, PostgreSQL reports SQLSTATE 57014 (query_canceled) while the connection may remain usable. See PostgreSQL Error 57014 and the query-cancellation documentation.

For other SQLSTATE guides, browse PostgreSQL Error Troubleshooting.