Horton

Re: Fix memory leak in gist_page_items() of pageinspect

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-12T09:48:09Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Use relation_close() more consistently in contrib/

  2. Use table/index_close() more consistently

  3. pageinspect: use index_close() for GiST index relation

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