As per a recent discussion in pgsql-admin, http://archives.postgresql.org/pgsql-admin/2006-09/msg00297.php libpq doesn't cope well with the situation where the server is configured to allow only SSL connections (or only non-SSL connections) and there is some unrelated-to-SSL connection problem such as wrong password. The reason is that libpq is set up to retry with the other kind of connection (either dropping or adding SSL) for just about any sort of error returned by the server. This may lead to reporting "no pg_hba.conf entry", or some such, rather than the more useful "password authentication failed".
I am tempted to propose that libpq should only retry in the other mode when the server specifically returns "no pg_hba.conf entry", and not for other server errors (beyond the initial do-you-do-SSL-at-all handshake of course). This would save a useless fork() cycle on the server as well as make it more likely that we return a useful error message. There are some corner cases where this might fail to connect when a blind retry would have succeeded, but they all involve the server offering different auth methods depending on SSL or not --- an example is "hostssl + ident" and "hostnossl + password", and you fail the ident test but could have produced the correct password. ISTM that is a scenario where the user should use the "sslmode" parameter to control which method is tried first. One problem with implementing this proposal is that we currently use the generic INVALID_AUTHORIZATION_SPECIFICATION sqlstate for a bunch of distinct conditions including "no pg_hba.conf entry". Looking directly at the error string is of course not localization-proof, so we'd have to break down that errcode into some more-specific categories. Which is probably not a bad idea anyway, but it would mean that the nicer behavior would only happen when talking to an 8.2 or later server. Thoughts? Is this something to tackle during beta, or must we put it off till 8.3? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq