| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Jason Petersen <jason(at)citusdata(dot)com> | 
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: BuildTupleFromCStrings Memory Documentation? | 
| Date: | 2015-05-01 04:19:20 | 
| Message-ID: | 37317.1430453960@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Jason Petersen <jason(at)citusdata(dot)com> writes:
> Within the core codebase, BuildTupleFromCStrings is often called within a temporary memory context cleared after the call. In dblink.c, this is justified as being needed to [clean up] not only the data we have direct access to, but any cruft the I/O functions might leak.
> I wrote a pretty minimal case to call BuildTupleFromCStrings in a loop (attached) and found that I was using 40GB of RAM in a few minutes, though I was not allocating any memory myself and immediately freed the tuple it returned.
> Is the need to wrap this call in a protective context documented anywhere? Portions of the documentation use BuildTupleFromCStrings in examples without mentioning this precaution. Is it just well-known, or did I miss a README or comment somewhere?
Most uses of BuildTupleFromCStrings only do it once per invocation of the
calling function, so that an outer-level reset of the calling function's
evaluation context is what takes care of any memory leaked by the I/O
functions BuildTupleFromCStrings invokes.  If you intend to call it many
times within the same function call then you should use a context you can
reset between calls.  This risk is hardly unique to BuildTupleFromCStrings,
which is why the documentation doesn't make a big point of it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2015-05-01 05:09:41 | Re: pg_rewind test race condition..? | 
| Previous Message | Peter Eisentraut | 2015-05-01 04:05:17 | Re: transforms vs. CLOBBER_CACHE_ALWAYS |