Re: BUG #15321: XMLTABLE leaks memory like crazy

2018-08-12 9:38 GMT+02:00 Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>:

> >>>>> "Pavel" == Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>
> Pavel> + MemoryContextReset(tstate->perValueCxt);
> Pavel> + MemoryContextSwitchTo(tstate->perValueCxt);
> Pavel> +
> Pavel> PG_TRY();
>
> Pavel> The reset of memory context is useless, because the reset of
> Pavel> perValueCxt is there already on the end of tfuncFetchRows
> Pavel> function
>
> It's overkill, yes, but it's also harmless because resetting a context
> that's not been touched since the last reset has very little overhead.
>
> Pavel> I don't understand to using tuple memory context
>
> We still need a per-result-tuple memory context otherwise we're leaking
> whatever memory got allocated in each GetValue call into the
> per-input-value context. (We can use our projection econtext's per-tuple
> memory for this because we haven't done any evaluation of output items
> for the current cycle yet at the point this code is reached.)
>
> Again, look at functionscan for how this is supposed to work.
>

it is done by tuplestore_putvalues

>
> Pavel> When we are running under perValueCxt, then there changing
> Pavel> memory context is useless
>
> It's not useless at all; it's needed to avoid excess memory usage when a
> single XMLTABLE() call returns many rows.
>

When this context was not necessary before, then it is not need be used
now. Tuplestore does all work

> --
> Andrew (irc:RhodiumToad)
>