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
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) |