From: Tom Lane <tgl@sss.pgh.pa.us>
To: mcarter@twosigma.com
cc: 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: <19411-0440c8897a04b638@postgresql.org>
References: <19411-0440c8897a04b638@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 16 Feb 2026 20:44:35 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1702504.1771347709.1@sss.pgh.pa.us>
Date: Tue, 17 Feb 2026 12:01:49 -0500
Message-ID: <1702505.1771347709@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1702505.1771347709%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> This report is for the libpq client library for PostgreSQL.

> I noticed the issue because my Apache Airflow task supervisor processes were
> experiencing memory growth of ~600 KB/min.  When running hundreds of tasks,
> my 32 GB machine OOM-crashed every few hours.  I traced the problem to when
> I upgraded libpq from version 13 to 16.  Varying Python version, and
> PostgreSQL DB version didn't make a difference.  When I updated to psycopg3,
> the leak rate dropped dramatically.

I think there are way too many moving parts here, and too few
configuration details, to allow assigning blame confidently.
I tried making a simple C test program that just connected, issued
BEGIN/UPDATE/COMMIT, and disconnected in a tight loop.  I see zero
leakage with that.  So either the leak isn't actually in libpq, or
there's some critical environmental factor you didn't mention.

Plausible such factors include connection type and authentication
method.  (For example, years ago libpq did leak memory while using
GSSAPI encryption.)  I tried both regular and SSL connections but
didn't really push hard on that, since I'd just be guessing blindly
about what your setup is.

			regards, tom lane