Since Npgsql 10.0 the default of GSS Encryption Mode= changed from Disable to Prefer.

The documentation already mentions that:

Some Linux environments do not have Kerberos installed. (...) it may generate an error such as the following: (...) Npgsql internally handles this (...) so the error is harmless.

What is not mentioned/considered there is the server-side effects of this change. Npgsql 10.0 now produces by default, the following log message and that on each connect:

2026-04-22 09:50:37.348 CEST [1277] LOG:  could not accept GSSAPI security context
2026-04-22 09:50:37.348 CEST [1277] DETAIL:  No credentials were supplied, or the credentials were unavailable or inaccessible: SPNEGO cannot find mechanisms to negotiate

or even better:

2026-04-22 09:16:01.857 CEST [29078] LOG:  could not accept GSSAPI security context
2026-04-22 09:16:01.857 CEST [29078] DETAIL:  An unsupported mechanism was requested: Unknown error

Resulting in a log file filling up with these messages unless GSS Encryption Mode=Disable is explicitly set. So I ask here if it was a good idea to have the default change or if Disable is better.

I also do not understand why in the table of https://www.npgsql.org/doc/security.html#gss-session-encryption-gss-api the first column is called SSL Mode, shouldn't it be GSS Encryption Mode?

And last, there could be also a bug somewhere because, again in the docu is written:

SSL Mode=Prefer results in "If there are GSSAPI credentials present (i.e., in a credentials cache), first try a GSSAPI-encrypted connection (...) if there are no credentials, try a non-GSSAPI-encrypted connection"

I do not have any credentials setup (explicitly set SSL Mode=Disable), why does it even try a encrypted connection? Per documentation it should not try it.