Horton

Re: Fix memory leak in gist_page_items() of pageinspect

Chao Li <li.evan.chao@gmail.com>

View thread
From: Chao Li <li.evan.chao@gmail.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Michael Paquier <michael@paquier.xyz>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-13T02:37:40Z
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

Attachments

On Dec 12, 2025, at 18:29, Daniel Gustafsson <daniel@yesql.se> wrote:

On 12 Dec 2025, at 11:27, Heikki Linnakangas <hlinnaka@iki.fi> wrote:


If we're going to bother changing this at all, let's consider reusing the
buffer. So instead of initStringInfo()+pfree on every tuple, allocate it
once and use resetStringInfo().


+1



It looks like there’s no disagreement on the index_close() fix, while the
StringInfo change has triggered some discussion.

So I’ve split the fix into two commits, which I probably should have done
from the beginning. 0001 contains the index_close() fix, and 0002 contains
the StringInfo fix.

As Heikki suggested, I switched to using resetStringInfo() in 0002. One
thing I’d like to highlight is that this function only uses the StringInfo
buffer under certain conditions. If we initialize the StringInfo
unconditionally, that feels wasteful; if we initialize it lazily, as in
0002, then we need some extra checks to manage its state.


Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/