A connection is not free just because it has not logged in yet. From the moment the TCP handshake completes, the would-be client is holding a backend slot counted against max_connections, and it will hold that slot until one of two things happens: it finishes the authentication protocol, or authentication_timeout kicks in and the server hangs up on it.
Default is 60 seconds. Minimum is 1, maximum is 600 (10 minutes). Context is sighup. If the number is specified without units, it’s seconds.
Sixty seconds is a long time for a client to complete SCRAM-SHA-256, and for most deployments the default is fine. The interesting case is the one the default exists to contain: a hung client, a broken load balancer, or an outright slow-loris-style attacker that opens TCP connections and never sends a valid startup packet. Each of those half-open connections ties up a slot for up to authentication_timeout seconds. With the default, 500 such connections and no mitigation will cheerfully saturate a cluster sized for max_connections = 500 for a full minute.
Two reasons you might tune this:
- Lower it — say, to 10 or 15 seconds — if you are seeing connection slot exhaustion from clients that connect and then never authenticate, and you haven’t yet sorted out a proper fix upstream (firewall rules, rate limiting, pgbouncer in front, a load balancer that does health checks correctly). Consider it a stopgap.
- Raise it if you are using Kerberos, LDAP, or PAM authentication and the external authentication service is genuinely slow. But if your LDAP directory takes more than 60 seconds to return a bind result, the GUC is not your actual problem.
Recommendation: Leave it at 60 seconds. If connection slots are being held by unauthenticated clients, the answer is almost always to put something in front of PostgreSQL that decides who gets to knock on the door in the first place. This parameter is the backstop, not the gate.