Alex <zhihui.fan1213@gmail.com> writes:
> I want to use valgrind to detect memory leak issue. Then I run into 2
> problems I want to confirm them here.
> 1. In https://wiki.postgresql.org/wiki/Valgrind, the wiki indicates to
> use '--leak-check=no'
That's just a sample configuration.
> 2. in https://github.com/afiskon/pgscripts/blob/master/valgrind.sh#L55,
> it use 'leak-check=no' as well with the wold "No point to check for memory
> leaks, Valgrind doesn't understand MemoryContexts and stuff"
That info is many years out-of-date. You can do it with USE_VALGRIND,
and sometimes that's helpful, but ...
> Q2: do we check memory leak for some new commits or we can ignore them
> based on we use memory context carefully? If we want to check memory leak
> for some new commits, how to handle the existing memory leak case?
Generally, the philosophy in PG is to not bother with freeing data
explicitly if letting it be reclaimed at context deletion is good enough.
Sometimes that's not good enough, but it is in most places, and for that
reason plain valgrind leak checking is of limited use.
valgrind can be pretty helpful if you're trying to identify the origin
of a serious leak --- the kind that accumulates memory wastage
repetitively over a query, for example. But what you have to do is
look for big leaks and ignore all the minor "leaks".
regards, tom lane