Re: libpq contention due to gss even when not using gss

> On Fri, Jun 14, 2024 at 12:12:55PM GMT, Daniel Gustafsson wrote:
> > I've been experimenting with both:
> >
> > * The server is built without gssapi, but the client does support it.
> > This produces exactly the contention you're talking about.
> >
> > * The server is built with gssapi, but do not use it in pg_hba, the
> > client does support gssapi. In this case the difference between
> > gssencmode=disable/prefer is even more dramatic in my test case
> > (milliseconds vs seconds) due to the environment with configured
> > kerberos (for other purposes, thus gss_init_sec_context spends huge
> > amount of time to still return nothing).
> >
> > At the same time after quick look I don't see an easy way to avoid that.
> > Current implementation tries to initialize gss before getting any
> > confirmation from the server whether it's supported. Doing this other
> > way around would probably just shift overhead to the server side.
>
> The main problem seems to be that we check whether or not there is a credential
> cache when we try to select encryption but not yet authentication, as a way to
> figure out if gssenc it as all worth trying?

Yep, this is my understanding as well. Which other methods did you try
for checking that?