| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Fix memory leak in gist_page_items() of pageinspect |
| Date: | 2025-12-12 09:48:09 |
| Message-ID: | aTvk2ctREcItpJQq@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chengpeng Yan | 2025-12-12 09:50:38 | Re: Add a greedy join search algorithm to handle large join problems |
| Previous Message | Rahila Syed | 2025-12-12 09:46:46 | Re: Enhancing Memory Context Statistics Reporting |