Michael Paquier <michael@paquier.xyz> writes:
> In my recent quest to look at GSSAPI builds on Windows, I have bumped
> into another failure that's related to this thread. hamerkop
> summarizes the situation here:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2021-05-29%2010%3A15%3A42
> There are two failures like this one as errorMessage piles up on
> failures, as of connect/test5:
> -[NO_PID]: ECPGconnect: connection to server failed: FATAL: database
> "regress_ecpg_user2" does not exist
> +[NO_PID]: ECPGconnect: connection to server failed: could not
> initiate GSSAPI security context: Unspecified GSS failure. Minor
> code may provide more information: Credential cache is empty
> +connection to server failed: FATAL: database "regress_ecpg_user2"
> does not exist
Yeah, I was looking at that earlier today. Evidently libpq is
trying a GSS-encrypted connection, and that doesn't work, so
it falls back to a regular connection where we get the expected
error. Probably all the connections in this test are hitting the
GSS failure, but only the ones where the second attempt fails
show a visible issue.
What is not clear is why GSS is acting that way. We wouldn't
have tried a GSS connection unless pg_GSS_have_cred_cache
succeeded ... so how come that worked but then gss_init_sec_context
complained "Credential cache is empty"?
My rough guess is that Windows has implemented the GSS APIs in
such a way that what pg_GSS_have_cred_cache is testing isn't
sufficient to tell whether a sane credential actually exists.
Or there's something particularly weird about how hamerkop
is set up.
regards, tom lane