Re: BUG #19411: libpq 16.x exhibits a memory leak when connections are repeatedly created and destroyed

Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> writes:
> On Fri, Oct 30, 2026 at 12:32 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> How can delegation succeed if there's nothing to delegate?

> IIUC, GSS_C_NO_CREDENTIAL doesn't actually mean "no credentials" to
> gss_init_sec_context(), it means "get the default credentials from
> somewhere magic." I don't know enough about the API to know whether
> the gss_acquire_cred() call we're making separately is equivalent to
> that magic behavior.

Oh, that's very interesting!

If you look back at v14, there is just one call to
pg_GSS_have_cred_cache, and AFAICS it happens unconditionally if
we attempt GSS encryption, and we don't reach any other
GSS code if it fails.

In the code as it stands, my coverage result says it's possible to
reach pg_GSS_continue without having already obtained credentials, but
I don't quite see how. select_next_encryption_method doesn't look
like it will permit using ENC_GSSAPI unless we obtain credentials.

Too bad this code is so poorly documented. It's really pretty unclear
what the intent is.

regards, tom lane