Re: Leaking memory in text_overlay function

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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Dirk Rudolph <dirk(dot)rudolph(at)netcentric(dot)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(dot)rudolph(at)netcentric(dot)biz | www.netcentric.biz