Feedback-ID: id4a34324:Fastmail
Date: Tue, 17 Feb 2026 14:45:17 -0500
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Matt Carter <Matt.Carter@twosigma.com>, 
	"pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #19411: libpq 16.x exhibits a memory leak when connections
 are repeatedly created and destroyed
Message-ID: <6xylkfh6idnx7ujhfhyoxku3v67ygoeve4yt7z2ytc65vzwvcv@z2sj5jnamhbe>
References: <19411-0440c8897a04b638@postgresql.org>
 <1702505.1771347709@sss.pgh.pa.us>
 <BL3PR08MB728301C87997AF17C743633A996DA@BL3PR08MB7283.namprd08.prod.outlook.com>
 <1881734.1771354069@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1881734.1771354069@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/6xylkfh6idnx7ujhfhyoxku3v67ygoeve4yt7z2ytc65vzwvcv%40z2sj5jnamhbe>
Precedence: bulk

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 specific to how psycopg2 uses libpq, not libpq itself.  I apologize for not including enough environmental details.  I used Kerberos/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/Kerberos authentication.
> 
> 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 the behavior.  Would testing with GSSAPI authentication help narrow this down? I can also report this to the psycopg2 project if 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