Re: OSX doesn't accept identical source/target for strcpy() anymore - Mailing list pgsql-hackers

From Tom Lane
Subject Re: OSX doesn't accept identical source/target for strcpy() anymore
Date
Msg-id 17900.1383009288@sss.pgh.pa.us
Whole thread Raw
In response to Re: OSX doesn't accept identical source/target for strcpy() anymore  (Andres Freund <andres@2ndquadrant.com>)
Responses 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  (Noah Misch <noah@leadboat.com>)
List 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 by date:

Previous
From: Naoya Anzai
Date:
Subject: Re: PostgreSQL Service on Windows does not start. ~ "is not a valid Win32 application"
Next
From: Andres Freund
Date:
Subject: missing RelationCloseSmgr in FreeFakeRelcacheEntry?