AW: Question about MemoryContexts / possible memory leak in CachedPlanSource usage

Ah, you are right, I looked in fe_memutils.c. Makes sense now, thanks!!

-----Ursprüngliche Nachricht-----
Von: Andres Freund <andres(at)anarazel(dot)de>
Gesendet: Donnerstag, 25. Juli 2019 22:31
An: Daniel Migowski <dmigowski(at)ikoffice(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Betreff: Re: Question about MemoryContexts / possible memory leak in CachedPlanSource usage

Hi,

On 2019-07-25 20:21:06 +0000, Daniel Migowski wrote:
> When CachedPlanSource instances are created the field query_string is
> filled with pstrdup(query_string) in CreateCachedPlan,
> plancache.c:182, which is just a wrapper for strdup. According to the
> docs the returned pointer should be freed with “free” sometimes later.

Note pstrdup is *not* just a wrapper for strdup:

return MemoryContextStrdup(CurrentMemoryContext, in);

i.e. it explicitly allocates memory in the current memory context.

Perhaps you looked at the version of pstrdup() in src/common/fe_memutils.c? That's just for "frontend" code (we call code that doesn't run in the server frontend, for reasons). There we don't have the whole memory context infrastructure... It's only there so we can reuse code that uses pstrdup() between frontend and server.

> I believe in DropCachedPlan the free should take place but I don’t see
> it. Is it just missing or is memory allocated by strdup and friends
> automatically created in the current MemoryContext? It so, why do I
> need to use palloc() instead of malloc()?

We don't intercept malloc itself (doing so would have a *lot* of issues, starting from palloc internally using malloc, and ending with having lots of problems with libraries because their malloc would suddenly behave differently).

Greetings,

Andres Freund