Re: Memory leak in vac_update_relstats ?
| От | NikhilS |
|---|---|
| Тема | Re: Memory leak in vac_update_relstats ? |
| Дата | |
| Msg-id | d3c4af540707200547w7d972cb5v3155932212bf6be2@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Memory leak in vac_update_relstats ? (NikhilS <nikkhils@gmail.com>) |
| Ответы |
Re: Memory leak in vac_update_relstats ?
|
| Список | pgsql-hackers |
Hi,
One specific case I want to mention here is hash_create(). For local hash tables if HASH_CONTEXT is not specified, they get created in a context which becomes a direct child of TopMemoryContext. Wouldn't it be a better idea to create the table in CurrentMemoryContext?
If hash_destroy() is not explicitly invoked, this can cause a lot of bloat especially if the intention was to use the hash table only for a while.
Regards,
Nikhils
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
That's the beauty of memory contexts for small allocations. But because of the 'convenience' of memory contexts we sometimes tend to not pay attention to doing explicit pfrees. As a general rule I think allocations in TopMemoryContext should be critically examined. I was bitten by this undue bloat recently while developing some code and valgrind is not of much help in such cases because of this very beauty of memory contexts :).
One specific case I want to mention here is hash_create(). For local hash tables if HASH_CONTEXT is not specified, they get created in a context which becomes a direct child of TopMemoryContext. Wouldn't it be a better idea to create the table in CurrentMemoryContext?
If hash_destroy() is not explicitly invoked, this can cause a lot of bloat especially if the intention was to use the hash table only for a while.
Regards,
Nikhils
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: