From PostgreSQL wiki
Valgrind and Postgres
Postgres 9.4 supports Valgrind memcheck directly - it is possible to include "client requests" in the memory allocator, providing detection of many additional memory others that would otherwise not be detected in vanilla builds. See src/include/pg_config_manual.h for full details of how to build Postgres with support for Valgrind memcheck instrumentation.
You should normally use MEMORY_CONTEXT_CHECKING with USE_VALGRIND; instrumentation of repalloc() is inferior without it.
If you observe core dumps in autovacuum while running under Valgrind on x86_64 hardware, it's probably a known bug in valgrind 3.8.1 and earlier; see https://bugs.kde.org/show_bug.cgi?id=280114. If you're prepared to recompile Valgrind, apply the one-line patch shown there. Otherwise, the simplest answer is to set autovacuum = off in postgresql.conf while using Valgrind. However, it's not clear that that "fix" will hide all instances of the issue.
One effective approach to gathering Valgrind memcheck instrumentation while running the regression tests is outlined here. A binary with debug symbols produces source file line numbers detail.
A Memcheck-hosted postgres can be started like this:
valgrind --leak-check=no --gen-suppressions=all \ --suppressions=src/tools/valgrind.supp --time-stamp=yes \ --log-file=$HOME/pg-valgrind/%p.log --trace-children=yes \ postgres --log_line_prefix="%m %p " \ --log_statement=all --shared_buffers=64MB 2>&1 | tee $HOME/pg-valgrind/postmaster.log
. Run the regression tests:
If that detected an error, and more details are required for debugging purposes, it is then possible to rerun a smaller test case with "--track-origins=yes --read-var-info=yes" flags also added. That slows things noticeably but gives more specific messaging. For more information, see the Valgrind documentation.
Run individual subsets of the regression tests, to limit the duration of testing:
make installcheck-tests TESTS="json combocid"
Not all tests in the regression tests are capable of being run on their own like this - you may wish to verify that each test passes without Postgres running through Valgrind first. (The file src/test/regress/parallel_schedule should give you some idea of the dependencies that the test of interest may have on other tests).