Re: BUG #15321: XMLTABLE leaks memory like crazy
От | Pavel Stehule |
---|---|
Тема | Re: BUG #15321: XMLTABLE leaks memory like crazy |
Дата | |
Msg-id | CAFj8pRD7bkGhn47wTw-CPhAQgH8OikezB=JrzVRsP_RAWH-scA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #15321: XMLTABLE leaks memory like crazy (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: BUG #15321: XMLTABLE leaks memory like crazy
|
Список | pgsql-bugs |
2018-08-12 9:38 GMT+02:00 Andrew Gierth <andrew@tao11.riddles.org.uk>:
>>>>> "Pavel" == Pavel Stehule <pavel.stehule@gmail.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)
В списке pgsql-bugs по дате отправления: