Re: Fix memory leak in gist_page_items() of pageinspect - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Fix memory leak in gist_page_items() of pageinspect
Date
Msg-id aTvk2ctREcItpJQq@paquier.xyz
Whole thread Raw
In response to Re: Fix memory leak in gist_page_items() of pageinspect  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Fix memory leak in gist_page_items() of pageinspect
Re: Fix memory leak in gist_page_items() of pageinspect
List pgsql-hackers
On Fri, Dec 12, 2025 at 09:00:08AM +0000, Bertrand Drouvot wrote:
> On Fri, Dec 12, 2025 at 04:50:09PM +0800, Chao Li wrote:
>> where CStringGetTextDatum() has made a copy of buf.data and assigned to
>> value[4], however buf.data is never free-ed.
>
> I did not look in details but I think that we should be in a short lived
> memory context here so we generally prefer to avoid using pfree for those cases.

The only thing that does a memory allocation is the StringInfo, why
would a memory context be worth the complication here?

> That might be a valid reason though. Do you have an idea of the "leak" size
> based on the number of tuples?

I presume that this just needs to imply a very large index, as we are
doing a simple loop with the items stored in a tuplestore
(CStringGetTextDatum does a palloc() for a value so we do not care
about the contents of the StringInfo).

The relation_close() inconsistency is a fun find.  We tend to be
careful with the APIs when opening relations and the ones that enforce
relkind checks, at least on style ground.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Rahila Syed
Date:
Subject: Re: Enhancing Memory Context Statistics Reporting
Next
From: Chengpeng Yan
Date:
Subject: Re: Add a greedy join search algorithm to handle large join problems