Re: libpq contention due to gss even when not using gss - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: libpq contention due to gss even when not using gss
Date
Msg-id u7r72mlyyp6ut42xuhdw4wafqnplk7tkjajoggq4uqpysbsmwn@sjnohtguu72j
Whole thread Raw
In response to Re: libpq contention due to gss even when not using gss  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
> 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?



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: RFC: adding pytest as a supported test framework
Next
From: Andres Freund
Date:
Subject: Re: libpq contention due to gss even when not using gss