PostgreSQL Field Guide

Troubleshoot PostgreSQL connection errors

Diagnose common failures in DNS, network, TLS, authentication, database, and connection capacity order

When failure happens before SQL execution, the client may not receive SQLSTATE. Preserve the complete error, timestamp, client version, and target host/port—but never the password.

Fixed diagnostic order

DNS resolution
 → TCP route/firewall/listening port
 → TLS negotiation and certificate identity
 → pg_hba.conf match
 → user authentication
 → database and CONNECT privilege
 → instance/pool connection capacity
 → session initialization settings

Resetting passwords or widening privileges before proving the previous layer usually hides the real cause.

Frequent errors

ErrorMeaningVerify
could not translate host nameDNS/hostname cannot resolvegetent hosts, nslookup, spelling, and private DNS
connection refusedNothing accepts the target address/portService state, listen_addresses, port, and container mapping
connection timed outNetwork path or firewall drops trafficTest TCP from the application environment, not a laptop substitute
no pg_hba.conf entryNo rule matches source/database/user/TLSInspect server log and rule order; reload after editing
password authentication failedCredential or authentication method mismatch, commonly SQLSTATE 28P01Confirm target instance/user and rotate securely
database ... does not existDatabase absent on this instance, SQLSTATE 3D000Connect to postgres and inspect pg_database
too many connectionsInstance/role/database limit exhausted, SQLSTATE 53300pg_stat_activity, pool size, and reserved administration access
certificate verify failedCA, hostname, validity, or chain mismatchsslmode, URI host, CA file, and provider rotation notice

Client verification

psql --version
psql -X "postgresql://app_reader@db.example.com:5432/commerce?sslmode=verify-full"

Immediately after success:

\conninfo
SELECT current_database(), current_user,
       inet_server_addr(), inet_server_port(),
       current_setting('server_version');

Minimal server-side checks

SELECT datname, datallowconn, datconnlimit
FROM pg_database
ORDER BY datname;

SELECT usename, application_name, client_addr, state, count(*)
FROM pg_stat_activity
GROUP BY usename, application_name, client_addr, state
ORDER BY count(*) DESC;

Use OS access only when needed to inspect listening sockets, firewalls, and PostgreSQL logs. For managed databases, use provider connection diagnostics, network flow logs, and audit logs.

Do not test passwords with trust

Changing pg_hba.conf to trust removes the authentication boundary and does not explain the original failure. Rotate credentials through a controlled channel and identify the matching HBA rule and server log entry.

For a secure successful connection, see psql and SSL. For SQL execution failures, use the SQLSTATE fieldbook.

Last updated on

On this page