Re: BUG #16112: large, unexpected memory consumption

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: ben(at)lantern(dot)is, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16112: large, unexpected memory consumption
Date: 2019-11-13 14:50:04
Message-ID: 20191113145004.opxx4vuajyoadbcq@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Nov 13, 2019 at 12:22:07PM +0000, PG Bug reporting form wrote:
>The following bug has been logged on the website:
>
>Bug reference: 16112
>Logged by: Ben Cornett
>Email address: ben(at)lantern(dot)is
>PostgreSQL version: 12.0
>Operating system: linux 2.6.32
>Description:
>
>Creation of table t1 in the query below causes the server process to consume
>close to 1GB of memory. The amount of memory consumed is proportional to
>the value passed to generate_series in the first query.
>
>CREATE temp TABLE t0 AS
>SELECT
> i,
> ARRAY[1,2,3] a
>FROM GENERATE_SERIES(1, 12000000) i
>;
>
>CREATE TEMP TABLE t1 AS
>SELECT
> i,
> x
>FROM t0, UNNEST(a) x;
>
>I observed the same behavior in other test queries that included implicit
>lateral joins.
>

Yeah, I can reproduce this pretty easily. It seems like a memory leak in
ExecMakeTableFunctionResult. a9c35cf85ca reworked FunctionCallInfo to be
variable-length, but it gets allocated in ExecutorState context directly
and so until the end of the query.

The attached trivial patch fixes that by adding a pfree() at the end of
the function. I wonder if we have the same issue elsewhere ...

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
memleak-a9c35cf85ca.patch text/plain 363 bytes

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2019-11-13 15:00:23 Re: 回复: BUG #16101: tables in the DB is not available after pg_restore
Previous Message Jeff Janes 2019-11-13 14:36:37 Re: REINDEX CONCURRENTLY unexpectedly fails