I found this thread on the open CF. As I see, the discussion is ended with decision to reject patch.

I've just changed the status to "Rejected".

02.07.2016 18:11, Dirk Rudolph:
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.


On Sat, Jul 2, 2016 at 4:45 PM, Tom Lane <t...@sss.pgh.pa.us <mailto:t...@sss.pgh.pa.us>> wrote:

    Dirk Rudolph <dirk.rudo...@netcentric.biz
    <mailto: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
    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

    There are places where it's important to avoid leaking memory,
    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 <mailto:dirk.rudo...@netcentric.biz> | www.netcentric.biz <http://www.netcentric.biz/>

Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Reply via email to