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  (Andres Freund <andres@2ndquadrant.com>)
Re: OSX doesn't accept identical source/target for strcpy() anymore  (Noah Misch <noah@leadboat.com>)
Список 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 по дате отправления:

Предыдущее
От: Naoya Anzai
Дата:
Сообщение: Re: PostgreSQL Service on Windows does not start. ~ "is not a valid Win32 application"
Следующее
От: Andres Freund
Дата:
Сообщение: missing RelationCloseSmgr in FreeFakeRelcacheEntry?