Есть такой проект heaptrack (https://github.com/KDE/heaptrack), который позволяет осуществлять профилирование памяти и пока читал всякое наткнулся на пост в котором рассказывали как с помощью него искать утечки памяти. В качестве "тренировочного стенда" взяли кодовую базу Postgres 17 и внесли туда ошибки работы с памятью.

Debugging memory leaks in Postgres, heaptrack edition
https://www.enterprisedb.com/blog/debugging-memory-leaks-postgres-heaptrack-edition

Эта статья естественно не является всеобъемлющим руководством, но хорошо показывает примеры работы "на пальцах".

С помощью Valgrind (https://valgrind.org/docs/manual/mc-manual.html) или LeakSanitizer (https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer) такого вида утечки, которые предлагают рассмотреть, обнаружить не получится

Remember that Postgres allocates memory in nested arenas called MemoryContexts. The top-level arena is called TopMemoryContext and it is freed as the process exits. Excessive allocations (leaks) in TopMemoryContext would not be caught by Valgrind memcheck or LeakSanitizer because the memory is actually freed as the process exits because TopMemoryContext is freed as the process exits. But while the process is alive, the above leak is real.

Первая часть посвящена поиску проблемы в серверной части. Ошибка была внесена в подсистему postmaster, которая отвечает за входящие соединения
https://www.postgresql.org/docs/current/connect-estab.html
https://postgrespro.ru/docs/postgresql/17/connect-estab

Триггерили утечку через вызов

 for run in {1..100000}; do ./build/bin/psql postgres -c 'select 1'; done

Вторая часть посвящена поиску внесённой ошибки в другой части PG

A memory leak in a client backend can be harder to catch since it is ephemeral. The client backend starts up for a single Postgres session and exits when the session exits. But so long as we can grab the PID of the client backend process, we can attach to it with heaptrack.

В данном случае для теста "сломали" генератор псевдослучайных чисел в бэке, а потом дёрнули запрос, который бы заиспользовал этот код
https://doxygen.postgresql.org/pseudorandomfuncs_8c.html#ac82ac41deb7429773a733890ad996944

Триггерили утечку через вызов

SELECT sum(random()) FROM generate_series(1, 10_000_000);

Я скринами прицепил трейсы на первый и второй случаи

Мне не понравился заключительный раздел (Considerations), выводы хотелось бы какие-то более интересные, чем что-то типа "хорошо бы уметь пользоваться не только Valgrind, но heaptrack"