Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Nothing has changed about when it fails, only the extra krb error
> message before the usual error messages (could not connect, server is
> starting up) are new. This probably has something to do with Magnus's
> work on concatenating rather than hiding error messages across multiple
> passes.
> I see this on Mac and Linux, so it should be reproducible with any
> Kerberos-enabled build.
Ah ... I had to try it on a machine *without* a credentials cache to
see something funny ;-)
What's happening is that pg_fe_getauthname -> pg_krb5_authname ->
pg_krb5_init fails and sets an error message in conn->errorMessage,
which we don't care about because we will get the username from
pqGetpwuid if Kerberos can't help us. But because of the concatenation
change, this gets added onto the (unrelated) later failure message.
I'm tempted to say that this code path simply shouldn't be setting
errorMessage at all. Alternatively we could have pg_fe_getauthname
clear out errorMessage upon successfully fetching a non-Kerberized
username ... but that would lose anything previously put into
errorMessage. (In which connection it seems like a bad thing that
pg_krb5_init uses printfPQExpBuffer rather than appendPQExpBuffer.)
Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
