Re: BUG #15321: XMLTABLE leaks memory like crazy

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: BUG #15321: XMLTABLE leaks memory like crazy
Дата
Msg-id CAFj8pRAwpBto2HSk2J8WNbBDokRH0eOZFCvYtW6ba-MK3DGm-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #15321: XMLTABLE leaks memory like crazy  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список 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.

The overhead is +/- zero. But the code will work exactly same without this line. So it is little bit confusing to use there.


 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.

 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.

--
Andrew (irc:RhodiumToad)

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: BUG #15321: XMLTABLE leaks memory like crazy
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: BUG #15321: XMLTABLE leaks memory like crazy