Stop retrying a PostgreSQL MCP connection you have not classified
Retrying a PostgreSQL MCP connection without classifying the failure can destroy the best evidence. The next attempt may resolve to another IP, use another certificate path, receive another pool connection, or replace t
Retrying a PostgreSQL MCP connection without classifying the failure can destroy the best evidence.
The next attempt may resolve to another IP, use another certificate path, receive another pool connection, or replace the original driver error with a generic timeout.
Capture a sanitized evidence bundle first:
- environment, region, runtime, and connector build
- target fingerprint, database name, and credential version β never the secret
- DNS answers and timing
- TCP outcome and duration
- TLS certificate fingerprint and verification result
- PostgreSQL SQLSTATE and sanitized message
- effective role, schema version, and catalog digest
- pool state, timeout settings, attempt number, and trace ID
Then classify the layer: configuration, DNS, TCP, TLS, authentication, authorization, schema, pool, or statement execution.
Retry bounded transient failures with backoff and jitter. Do not retry invalid credentials, certificate identity failures, authorization denials, wrong environments, missing approved objects, or policy rejections.
βConnection failedβ is not a useful error contract. A stable failure code, layer, retryability decision, safe message, and trace ID is.
Full guide: MCP server Postgres connection troubleshooting with an evidence bundle
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.