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

Matt Carter <Matt(dot)Carter(at)twosigma(dot)com> writes:
> Tom Lane wrote:
>> I propose changing its name altogether, as attached.

> Thanks, Tom. I tested your patch against my GSSAPI-authenticated server (MIT krb5 1.20.1, OpenSSL 1.1). It applies to 18.3 with line offsets and builds without warnings. Using the reproducer from my previous message, these are the bytes per connection still allocated after warm-up (450 connections):

> 18.3 unpatched 17844
> 18.3 + your patch 108
> 18.3 + your patch, gssencmode=disable 42

> GSSAPI authentication works as before.

Thanks for testing that, but after looking closer, I believe that
pg_GSS_continue has even more problems here. It will attempt to
acquire credentials whether or not GSS delegation is enabled,
contrary to the adjacent comment and unlike what happens in
pqsecure_open_gss. And if GSS delegation is enabled, it will
set the GSS_C_DELEG_FLAG whether or not it was able to acquire
credentials, which seems not very sane and again different from
the logic in pqsecure_open_gss. So I think what we really need
is more like the attached. This passes our own test suite, but
I wonder if you can exercise it in your own environment.

> We would benefit from back-patches to 16 and 17:

Yeah, this problem was visibly introduced in v16 when we added
GSS delegation support, so I anticipate back-patching that far.

regards, tom lane