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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Daniel Migowski <dmigowski(at)ikoffice(dot)de>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Question about MemoryContexts / possible memory leak in CachedPlanSource usage
Date: 2019-07-25 20:30:48
Message-ID: 20190725203048.sasn7423flnbyzmo@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-07-25 20:35:15 Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)
Previous Message Bruce Momjian 2019-07-25 20:27:12 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)