Re: BUG #16112: large, unexpected memory consumption - Mailing list pgsql-bugs

From Jeff Janes
Subject Re: BUG #16112: large, unexpected memory consumption
Date
Msg-id CAMkU=1yXNf_=dFtOkp=M2kXs1RHPgUddxAv3qDfyAfOEOz=YnA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16112: large, unexpected memory consumption  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: BUG #16112: large, unexpected memory consumption  (Andres Freund <andres@anarazel.de>)
Re: BUG #16112: large, unexpected memory consumption  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-bugs
On Wed, Nov 13, 2019 at 9:50 AM Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:

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.

I find the leak was introduced much earlier than that, in:

commit 763f2edd92095b1ca2f4476da073a28505c13820
Author: Andres Freund <andres@anarazel.de>
Date:   Thu Nov 15 14:26:14 2018 -0800

    Rejigger materializing and fetching a HeapTuple from a slot.
 
I have no idea if this info is useful to informing the best solution, though.

You patch applied to REL_12_STABLE does fix it for me.


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


Is there an easy way to assess if the "make check" regression tests are taking more memory than they used to?

Cheers,

Jeff 

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Unexpected "cache lookup failed for collation 0" failure
Next
From: Andres Freund
Date:
Subject: Re: BUG #16112: large, unexpected memory consumption