Re: OSX doesn't accept identical source/target for strcpy() anymore
От | Tom Lane |
---|---|
Тема | Re: OSX doesn't accept identical source/target for strcpy() anymore |
Дата | |
Msg-id | 17900.1383009288@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: OSX doesn't accept identical source/target for strcpy() anymore (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: OSX doesn't accept identical source/target for
strcpy() anymore
Re: OSX doesn't accept identical source/target for strcpy() anymore |
Список | pgsql-hackers |
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; but there are far worse problems: 1. The output goes to stderr which means it's mixed in with the backend's normal log chatter. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: