Re: Fix memory leak in gist_page_items() of pageinspect
| От | Michael Paquier |
|---|---|
| Тема | Re: Fix memory leak in gist_page_items() of pageinspect |
| Дата | |
| Msg-id | aTvk2ctREcItpJQq@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Fix memory leak in gist_page_items() of pageinspect (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
| Ответы |
Re: Fix memory leak in gist_page_items() of pageinspect
Re: Fix memory leak in gist_page_items() of pageinspect |
| Список | 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
Вложения
В списке pgsql-hackers по дате отправления: