Description

After upgrading to Npgsql 10, services running on Alpine Linux containers (without Kerberos) experience a memory leak that leads to OOM kills. The root cause is the new default GssEncryptionMode=Prefer — Npgsql 10 attempts GSSAPI negotiation on every new connection, and on Linux without libgssapi_krb5.so.2, connections hang indefinitely during the SSL fallback.

Environment

• Npgsql version: 10.0.2 (pulled transitively via Npgsql.OpenTelemetry 10.0.2)
• Previous Npgsql version: 9.0.4 (unaffected)
• Runtime: .NET 9, Alpine Linux containers
• GssEncryptionMode: not set (default Prefer)

Observed behavior

Connections get stuck permanently at:

ConnectAsync → RawOpen → NegotiateEncryption → SetupEncryption → SslStream.ForceAuthenticationAsync

Heap analysis with dotnet-dump showed:

• 70 NpgsqlConnector instances accumulating in ~29 minutes
• GC roots tracing through Timer → TimerCallback → ... → SslStream.ForceAuthenticationAsync
• Connections are never completed, never disposed, never GC'd

Memory growth is continuous and eventually causes OOM kills in Kubernetes.

Expected behavior

On systems without Kerberos, GSSAPI negotiation should fail fast and fall back gracefully — connections should complete or fail cleanly, not hang indefinitely.

Workaround

Adding GssEncryptionMode=Disable to the connection string resolves the issue completely. Memory stabilizes immediately. Confirmed in multiple production services.

Comparison with Npgsql 9.x

Npgsql 9.0.4 (no GSSAPI support) does not exhibit this behavior — connections complete successfully.

Additional context

Discovered while investigating OOM kills across multiple Kubernetes services after an unintentional upgrade to Npgsql 10 via Npgsql.OpenTelemetry 10.0.2. The hang only occurs on Linux without Kerberos and is fully reproducible.