On Mon, Oct 28, 2013 at 09:14:48PM -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-10-28 16:02:36 -0400, Tom Lane wrote:
> >> The larger problem though is what you'd do with the output. There's
> >> enough false-positive noise from valgrind that I can't see having
> >> the buildfarm run just fail if there are any messages. What to do
> >> instead isn't very clear.
>
> > The false positives should be gone using the suppressions file we ship
> > these days (--suppressions=/path/to/pg/src/tools/valgrind.supp). We
> > might miss some more cases there, but it should be fairly easy to extend
> > it.
>
> They're not all gone according to my testing
True. Getting a clean Valgrind report is similar to getting the build
warning-free. Variations of compiler version, optimization level, host OS,
and CPU architecture can all affect the set of errors Valgrind reports, just
as they affect compiler warnings. Valgrind cleanliness has a lot of catching
up to do.
I never ran initdb under Valgrind, just "make installcheck", so that's novel
territory.
> 1. The output goes to stderr which means it's mixed in with the backend's
> normal log chatter.
As Andres explained, this is strictly a local configuration choice.
> 2. valgrind causes autovacuum to dump core, at least on my box (RHEL6).
Don't bother with versions older than Valgrind 3.8.1. Besides having a fix
for that bug, it runs PostgreSQL an order of magnitude faster, per the comment
in pg_config_manual.h.
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
