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 |
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 |