On Wed, Jul 26, 2017 at 6:51 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > Hi hackers, > > Some LDAP error codes are a bit vague. For example: > > LDAP_CONNECT_ERROR Indicates a connection problem. > LDAP_PROTOCOL_ERROR A protocol violation was detected. > > To learn more, you have to call > ldap_get_option(LDAP_OPT_DIAGNOSTIC_MESSAGE). Should we do that? For > example, instead of: > > LOG: could not start LDAP TLS session: Protocol error > > ... you could see: > > LOG: could not start LDAP TLS session: Protocol error > DETAIL: LDAP diagnostic message: unsupported extended operation > > Well, that may not be the most illuminating example, but that's a > message sent back by the LDAP server that we're currently throwing > away, and can be used to distinguish between unsupported TLS versions, > missing StartTLS extension and various other cases. Perhaps that > particular message would also be available via your LDAP server's > logs, if you can access them, but in some cases we're throwing away > client-side messages that are not available anywhere else like "TLS: > unable to get CN from peer certificate", "TLS: hostname does not match > CN in peer certificate" and more. >
+1. > Something like the attached. The patch prints errdetail() as "No LDAP diagnostic message available." when LDAP doesn't provide diagnostics. May be some error messages do not have any diagnostic information. In that case above error detail may be confusing. May be we should just omit error details when diagnostic message is not available. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
