Re: Leaking memory in text_overlay function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dirk Rudolph <dirk(dot)rudolph(at)netcentric(dot)biz>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Leaking memory in text_overlay function
Date: 2016-07-02 14:45:14
Message-ID: 30435.1467470714@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. Im 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-07-02 15:07:02 Re: Bug in batch tuplesort memory CLUSTER case (9.6 only)
Previous Message Bruce Momjian 2016-07-02 14:42:55 Re: Docs, backups, and MS VSS