Michael Paquier <michael@paquier.xyz> writes:
> On Mon, May 31, 2021 at 12:05:12AM -0400, Tom Lane wrote:
>> 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"?
> 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.
Interesting --- I was considering running such a test locally, but
didn't get round to it yet.
> 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 seems like the ideal solution would be to make pg_GSS_have_cred_cache
smarter, so that we don't attempt a GSS connection cycle here. But if
we can't, adding gssencmode=disable to these test cases is what I was
thinking about, too.
> 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..
Agreed, that seems bogus.
regards, tom lane