On Wed, Nov 13, 2019 at 05:53:28PM -0500, Jeff Janes wrote:
>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.
>
Ah, I've only done a simple 'git blame' and assumed it's the last commit
that touched the palloc line (and it seemed somewhat plausible). I don't
think it changes the reasoning too much, 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?
>
Probably not. The regression tests use fairly small number of rows in
general, and we don't have a way to track/inspect high watermaks or
anything like that anyway.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services