On 13/06/2026 15:54, Tomas Vondra wrote: > Anyway, it seems very convenient to use, and gives me data roughly in > line with the manual tracing. It produces much nicer / more complete > reports, and it's way faster (a minute vs. an hour).
>From my side, I've spent some time working with heaptrack. VALGRIND's macros work well for counting memory context allocations. However, they do not cover memory context resets. Each type of memory reset - aset, generation, and bump - needs its own custom routine. For bump.c, we also need to use memory-checking tools to ensure memory chunks are handled correctly during reset. Another issue is that heaptrack turns off custom mem alloc and free reports in each forked process. Because of this, I found no other way to re-enable it in a specific backend than to write a trivial extension. There are some positive possibilities if heaptrack is updated. If it will add the 'tagged' memory allocations feature, we could get a clear allocation profile for each context, including system malloc and free calls. Overall, this tool looks promising. It is lightweight, precise, provides detailed information, and is widely used by support teams on Linux and Windows. However, it needs some changes before postgres can use it. For now, it is not a viable option. -- regards, Andrei Lepikhov, pgEdge
