Re: Extended Statistics set/restore/clear functions. - Mailing list pgsql-hackers

From Chao Li
Subject Re: Extended Statistics set/restore/clear functions.
Date
Msg-id 23E399F9-B0EC-4B00-8349-C76206445A41@gmail.com
Whole thread Raw
In response to Re: Extended Statistics set/restore/clear functions.  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Extended Statistics set/restore/clear functions.
List pgsql-hackers

> On Jan 19, 2026, at 14:11, Michael Paquier <michael@paquier.xyz> wrote:
>
>> vatuples[I] is returned by SearchSysCacheCopy1(), I believe it
>> should be free by heap_freetuple(). See the header comment of
>> SearchSysCacheCopy().
>
> Here I believe that the issue is different: vatuples is not needed at
> all, and can be removed.  We use it nowhere in when importing a MCV
> list.

Hi Michael,

May I ask an off-list question?

Should tuples returned by SearchSysCacheCopy1() always be explicitly freed with heap_freetuple()? I’ve long had the
understandingthat the answer is “yes”. 

However, recently I’ve seen some patches addressing apparent memory leaks deemed unnecessary on the grounds that the
surroundingmemory context would clean things up anyway. That made me unsure whether the same reasoning is considered
acceptablefor tuples returned by SearchSysCacheCopy1(), or whether the expectation is still that callers should free
themexplicitly. 

I’d appreciate any clarification on the question. Thanks in advance.

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







pgsql-hackers by date:

Previous
From: Oleg Tselebrovskiy
Date:
Subject: Re: 001_password.pl fails with --without-readline
Next
From: Tatsuro Yamada
Date:
Subject: Re: [PATCH] psql: add \dcs to list all constraints