On Mon, May 31, 2021 at 12:05:12AM -0400, Tom Lane wrote:
> 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.
Yep. This wastes cycles.
> 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.
I suspect that's just the way the upstream installation works with a
credentials cache created from the beginning, as I see the same
behavior and the same error on my own host for HEAD with a KRB5 server
set up once the upstream installation runs. Leaving the specific
topic of this thread aside for one moment, would there be an argument
for just enforcing gssencmode=disable in this set of tests down to 12?
It is worth noting that the problem does not show up in 12 and 13 once
the compilation works, because we just mask the error there, but the
code path is still taken.
Another thing that strikes me as incorrect is that we don't unset
PGGSSENCMODE or PGGSSLIB in TestLib.pm. Just noting it on the way..
--
Michael