From: Tom Lane <tgl@sss.pgh.pa.us>
To: Matt Carter <Matt.Carter@twosigma.com>
cc: "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
In-reply-to: <BL3PR08MB728301C87997AF17C743633A996DA@BL3PR08MB7283.namprd08.prod.outlook.com>
References: <19411-0440c8897a04b638@postgresql.org> <1702505.1771347709@sss.pgh.pa.us> <BL3PR08MB728301C87997AF17C743633A996DA@BL3PR08MB7283.namprd08.prod.outlook.com>
Comments: In-reply-to Matt Carter <Matt.Carter@twosigma.com>
	message dated "Tue, 17 Feb 2026 17:54:17 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1881733.1771354069.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 17 Feb 2026 13:47:49 -0500
Message-ID: <1881734.1771354069@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1881734.1771354069%40sss.pgh.pa.us>
Precedence: bulk

Matt Carter <Matt.Carter@twosigma.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think there are way too many moving parts here, and too few configura=
tion details,
>> to allow assigning blame confidently.

> 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 environment=
al details.  I used Kerberos/GSSAPI with SSL (TLS 1.2 connections).  My co=
nnection string was: "postgresql://hostname/database" (no password, Kerber=
os auth).
> Your mention of "years ago libpq did leak memory while using GSSAPI encr=
yption" 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.

> I can test with non-GSSAPI authentication to try to isolate that variabl=
e.  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 nar=
row 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.

			regards, tom lane