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)
Date: Mon, 18 Mar 2019 12:33:31 -0400
Message-ID: <16717.1552926811@sss.pgh.pa.us> (raw)
In-Reply-To: <15700-8c408321a87d56bb@postgresql.org>
References: <15700-8c408321a87d56bb@postgresql.org>
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); 134220840 used
> I know that I'm also using the JDBC driver here which of course could also
> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, mo@otterbach.eu, 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: <16717.1552926811@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox