Re: libpq contention due to gss even when not using gss
От | Dmitry Dolgov |
---|---|
Тема | Re: libpq contention due to gss even when not using gss |
Дата | |
Msg-id | u7r72mlyyp6ut42xuhdw4wafqnplk7tkjajoggq4uqpysbsmwn@sjnohtguu72j обсуждение исходный текст |
Ответ на | Re: libpq contention due to gss even when not using gss (Daniel Gustafsson <daniel@yesql.se>) |
Список | 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 по дате отправления: