From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15321: XMLTABLE leaks memory like crazy |
Date: | 2018-08-11 00:28:47 |
Message-ID: | 87va8h7nyl.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>>>>> "PG" == PG Bug reporting form <noreply(at)postgresql(dot)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)
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2018-08-11 03:00:04 | Re: BUG #15321: XMLTABLE leaks memory like crazy |
Previous Message | PG Bug reporting form | 2018-08-10 23:33:55 | BUG #15321: XMLTABLE leaks memory like crazy |