From: Tom Lane <tgl@sss.pgh.pa.us>
To: mo@otterbach.eu
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15700: PG 10 vs. 11: Large increase in memory usage when
 selecting BYTEA data (maybe memory leak)
In-reply-to: <15700-8c408321a87d56bb@postgresql.org>
References: <15700-8c408321a87d56bb@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 18 Mar 2019 09:44:34 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <16716.1552926811.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 18 Mar 2019 12:33:31 -0400
Message-ID: <16717.1552926811@sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> [ apparent backend memory leak when processing wide rows ]

FWIW, I tried to reproduce this without success, on both HEAD and v11
branch tip.  It's possible that this is a bug somebody fixed since
11.2, but I see no mention of relevant memory leaks in the commit log.
Still, it's hard to interpret this:

>       ExecutorState: 4294976384 total in 17 blocks; 4080 free (0 chunks)=
;
> 4294972304 used

as anything but a leak in ExecutorState.  For comparison, when I try
this same example here, I get a fairly steady value of

      ExecutorState: 134225984 total in 2 blocks; 5144 free (1 chunks); 13=
4220840 used

> I know that I'm also using the JDBC driver here which of course could al=
so
> cause the bug, it might be a JDBC driver bug for which I should report a=
 bug
> elsewhere.

I confess that I'm not actually trying this with JDBC, but with
libpq (via psql and pgbench).  One could imagine that JDBC is
presenting the query sufficiently differently to cause different
backend behavior, say by asking for binary not text output ---
but I tried that, no change.

I think there must be some other moving parts you haven't mentioned.
Maybe you have some PG extension(s) installed?

			regards, tom lane