On 2013-10-28 21:14:48 -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; but there are far worse > problems:
Spurious or real bugs? Inside PG or libc? > 1. The output goes to stderr which means it's mixed in with the backend's > normal log chatter. That's relatively easy to fix. We could just pass --log-file redirecting the errors somewhere special and display them there. What I've done so far is to tell valgrind to let child processes with errors exit with a non-zero exitcode using the --error-exitcode parameter and specify -q to reduce the chatter upon normal process exit. That gives at least some correlation to the errors in the failed tests. > 2. valgrind causes autovacuum to dump core, at least on my box (RHEL6). > I'm prepared to believe that this is some relatively old bug that Red Hat > hasn't gotten round to including a patch for, but still it doesn't leave > me with any warm fuzzy feeling about the practicality of routine valgrind > testing. Yea, I know which bug that is, I've pushed the valgrind guys into fixing it... valgrind used to get confused about stack alignment in signal handlers causing instructions that care about that (mostly xmm* register using ones) to fail. elog() fails because we frequently pass many parameters. Since we fork processes from inside signal handlers, that situation happens pretty often. https://bugs.kde.org/show_bug.cgi?id=280114 3. valgrind gets floating point computations for exp(larger_negative_double) wrong and returns the wrong error message: regression=# SELECT exp(-808.3::float8); ERROR: value out of range: overflow exp sets errno=ERANGE and returns inf. That's not supposed to happen according to my exp(3)... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers