Sets a maximum time to wait when establishing a connection to an Amazon Redshift cluster.
Network latency, DNS hiccups, or overloaded clusters can leave your SQL client waiting indefinitely. Adding a timeout parameter forces the client to abort after a user-defined number of seconds, returning control to your application quickly.
Add connect_timeout=<seconds>
to any libpq-compatible string. The timer starts when the TCP handshake begins and stops when authentication succeeds.
psql "host=redshift-cluster.abc.us-east-1.redshift.amazonaws.com port=5439 dbname=dev user=awsuser connect_timeout=10"
jdbc:postgresql://redshift-cluster.abc.us-east-1.redshift.amazonaws.com:5439/dev?connectTimeout=10
Use SET statement_timeout
. Unlike connect_timeout
, this parameter controls how long any single statement may run before being canceled by the server.
SET statement_timeout TO '15s';
Short timeouts (5-15 s) keep orchestration tools from stalling when clusters reboot. Longer timeouts (30-60 s) suit interactive BI sessions, allowing transient network spikes to clear.
The client raises an error such as could not connect to server: Operation timed out
. Handling this exception lets your code retry, alert, or fail gracefully.
No. The timer runs entirely in the client library (psql, JDBC, psycopg2, etc.). Redshift itself is unaware of the parameter.
No. You must disconnect and reconnect with a new parameter or environment variable to modify the connection timeout.
libpq defaults to no timeout (wait forever). Some drivers override this to 10 s, so always set it explicitly for predictable behavior.