Hi,
On 2026-02-17 13:47:49 -0500, Tom Lane wrote:
> Matt Carter <Matt.Carter@twosigma.com> writes:
> > Thank you for taking the time to test this and for the feedback. Your C test showing no leak suggests the issue is
specificto how psycopg2 uses libpq, not libpq itself. I apologize for not including enough environmental details. I
usedKerberos/GSSAPI with SSL (TLS 1.2 connections). My connection string was: "postgresql://hostname/database" (no
password,Kerberos auth).
> > Your mention of "years ago libpq did leak memory while using GSSAPI encryption" is interesting because we ARE using
GSSAPI/Kerberosauthentication.
>
> Interesting. I wondered about GSSAPI, but spinning up such an
> environment is more work than I wanted to do on speculation.
Heh, understandable...
> > I can test with non-GSSAPI authentication to try to isolate that variable. I can also create a pure psycopg2
reproducer(without SQLAlchemy). I can also test whether disabling GSSAPI encryption (but keeping GSSAPI auth) changes
thebehavior. Would testing with GSSAPI authentication help narrow this down? I can also report this to the psycopg2
projectif you think it's their issue.
>
> Please try varying the connection type and encryption. I do suspect
> this may be psycopg2's fault, but we lack enough data to pin blame
> as yet.
Matt, you could try analyzing the memory usage with heaptrack, it tends to be
pretty good at finding them even in uninstrumented builds, as long as enough
debug symbols for a backtrace are available. Often enough it'll pinpoint
where the leak is coming from quite easily (but note that it will report some
constant-sized leaks that are "intentional").
Greetings,
Andres
