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:
> Your suspicion was right, and I'm sorry for pointing at psycopg2 earlier. The leak is in libpq, and it needs GSSAPI *authentication*. Every connection to my server authenticates via "gss" in pg_hba.conf. My gssencmode=disable runs only turned off GSS encryption, so none of my tests ever removed it.

> pg_GSS_continue() runs once per GSS round trip, and Kerberos with mutual authentication takes two. On every call it does

> /* Only try to acquire credentials if GSS delegation isn't disabled. */
> if (!pg_GSS_have_cred_cache(&conn->gcred))
> conn->gcred = GSS_C_NO_CREDENTIAL;

> pg_GSS_have_cred_cache() calls gss_acquire_cred() and stores the result in *cred_out. It doesn't release the credential that is already there.

Ooops. It looks like this isn't the only place that makes that
mistake: select_next_encryption_method seems at risk too, or at least
if it's not, that's because of caller logic not anything it's doing
itself. I think that's partially because pg_GSS_have_cred_cache is
poorly named: it sounds like a status test not an action, and its API
is just bizarre. I propose changing its name altogether, as attached.

regards, tom lane