Re: OSX doesn't accept identical source/target for strcpy() anymore

On Mon, Oct 28, 2013 at 09:14:48PM -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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