On Mon, Oct 28, 2013 at 09:14:48PM -0400, Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
