Re: BUG #15321: XMLTABLE leaks memory like crazy
От | Andrew Gierth |
---|---|
Тема | Re: BUG #15321: XMLTABLE leaks memory like crazy |
Дата | |
Msg-id | 87va8h7nyl.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | BUG #15321: XMLTABLE leaks memory like crazy (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #15321: XMLTABLE leaks memory like crazy
|
Список | pgsql-bugs |
>>>>> "PG" == PG Bug reporting form <noreply@postgresql.org> writes: PG> From a report on IRC: PG> XMLTABLE runs a lot of setup code in the per-query memory context - PG> resulting in allocations of copies of namespace names, other PG> values, and _multiple copies of the passed-in XML document_, which PG> are not freed anywhere. Alvaro, I think this comment of yours from when you committed this work is relevant: >> I just pushed XMLTABLE, after some additional changes. Please test >> it thoroughly and report any problems. [...] >> Some changes I made: >> * I removed the "buildercxt" memory context. It seemed mostly >> pointless, and I was disturbed by the MemoryContextResetOnly(). >> Per-value memory still uses the per-value memory context, but the >> rest of the stuff is in the per-query context, which should be >> pretty much the same. A quick reading suggests that the per-value context should have been changed to not be a child of "buildercxt" (which would avoid the MemoryContextResetOnly issue - that's a good sign that you've put a child context under the wrong parent). But the use of the per-query context instead is exactly what causes this blowup; compare with what nodeFunctionscan does with its "argcontext" (and the corresponding comments in ExecMakeTableFunctionResult). -- Andrew (irc:RhodiumToad)
В списке pgsql-bugs по дате отправления: