Re: Fix memory leak in gist_page_items() of pageinspect

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix memory leak in gist_page_items() of pageinspect
Date: 2025-12-12 09:48:09
Message-ID: aTvk2ctREcItpJQq@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chengpeng Yan 2025-12-12 09:50:38 Re: Add a greedy join search algorithm to handle large join problems
Previous Message Rahila Syed 2025-12-12 09:46:46 Re: Enhancing Memory Context Statistics Reporting