| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Extended Statistics set/restore/clear functions. |
| Date: | 2026-01-19 08:56:25 |
| Message-ID: | 23E399F9-B0EC-4B00-8349-C76206445A41@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Jan 19, 2026, at 14:11, Michael Paquier <michael(at)paquier(dot)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 understanding that the answer is “yes”.
However, recently I’ve seen some patches addressing apparent memory leaks deemed unnecessary on the grounds that the surrounding memory context would clean things up anyway. That made me unsure whether the same reasoning is considered acceptable for tuples returned by SearchSysCacheCopy1(), or whether the expectation is still that callers should free them explicitly.
I’d appreciate any clarification on the question. Thanks in advance.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuro Yamada | 2026-01-19 09:22:18 | Re: [PATCH] psql: add \dcs to list all constraints |
| Previous Message | Oleg Tselebrovskiy | 2026-01-19 08:44:45 | Re: 001_password.pl fails with --without-readline |