Well that's good to know. It was just curious that, in my case, I only saw this in this particular function.
Anyway. I will consider to handle the memory the same way, if this is the recommendation. Many thanks. /Closed On Sat, Jul 2, 2016 at 4:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dirk Rudolph <dirk.rudo...@netcentric.biz> writes: > > while implementing my own C function, I mentioned that some memory is > not freed by the text_overlay function in varlena.c > > By and large, that's intentional. SQL-called functions normally run > in short-lived memory contexts, so that any memory they don't bother to > pfree will be cleaned up automatically at the end of the tuple cycle. > If we did not follow that approach, there would need to be many thousands > more explicit pfree calls than there are today, and the system would be > net slower overall because multiple retail pfree's are slower than a > MemoryContextReset. > > There are places where it's important to avoid leaking memory, certainly. > But I don't think this is one of them, unless you can demonstrate a > scenario with query-lifespan or worse leakage. > > > Particularly I mean the both substrings allocated by text_substring > (according to the documentation of text_substring "The result is always a > freshly palloc'd datum.") and one of the concatenation results. I’m aware > of the MemoryContext being deleted in my case but IMHO builtin functions > should be memory safe. > > That is not the project policy. > > regards, tom lane > -- Dirk Rudolph | Senior Software Engineer Netcentric AG M: +41 79 642 37 11 D: +49 174 966 84 34 dirk.rudo...@netcentric.biz | www.netcentric.biz
