Re: Fix memory leak in gist_page_items() of pageinspect

Hi,

On Sat, Dec 13, 2025 at 10:37:40AM +0800, Chao Li wrote:
> On Dec 12, 2025, at 18:29, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> On 12 Dec 2025, at 11:27, Heikki Linnakangas <hlinnaka(at)iki(dot)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
>
> 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.

I think that 0002 works fine.

I'm just wondering if:

+ StringInfoData buf = {0}; /* mark as uninitialized */

does not "break" the semantic of "maxlen == 0" means "read-only".

According to the StringInfoData definition comments:

"
* As a special case, a StringInfoData can be initialized with a read-only
* string buffer. In this case "data" does not necessarily point at a
* palloc'd chunk, and management of the buffer storage is the caller's
* responsibility. maxlen is set to zero to indicate that this is the case.
* Read-only StringInfoDatas cannot be appended to or reset.
* Also, it is caller's option whether a read-only string buffer has a
* terminating '\0' or not. This depends on the intended usage."

The patch uses maxlen == 0 to detect "uninitialized", but the documentation
explicitly says maxlen == 0 indicates "read-only". Maybe adjust the doc a bit or
add a buf_initialized bool in gist_page_items instead?

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com