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

Reply via email to