From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Re: BUG #15321: XMLTABLE leaks memory like crazy |
Date: | 2018-08-12 11:18:07 |
Message-ID: | 877ekv7s9j.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>>>>> "Pavel" == Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> But that's not "immediately" because tfuncLoadRows is looping over
>> the FetchRow call, and calling GetValue for each column in that row,
>> and in your version it is _not cleaning up memory in that loop_.
Pavel> ok, now I am maybe understand to your motivation.
Pavel> Usually, loading row should be memory cheap operation, but sure
Pavel> some bytes it can take.
Yes, it'll usually be small, but you shouldn't assume that (and some
type input functions may use more memory than you think, since doing a
lot of retail pfree() calls can really slow things down).
Pavel> Then I don't like too much using ecxt_per_tuple_memory for this.
It's there, it has the right lifetime, allocating another one just for
this is a waste. Furthermore, this is the same pattern that FunctionScan
uses, so it's more consistent.
Pavel> Or do better comments about using this memory context for very
Pavel> short life task, please.
What specifically do you think needs explaining?
Attached patch is the same logic as before but with more comments.
--
Andrew (irc:RhodiumToad)
Attachment | Content-Type | Size |
---|---|---|
xmlmem.patch | text/x-patch | 2.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2018-08-12 12:27:56 | Re: BUG #15321: XMLTABLE leaks memory like crazy |
Previous Message | Pavel Stehule | 2018-08-12 10:39:44 | Re: BUG #15321: XMLTABLE leaks memory like crazy |