Re: valgrind issues on Fedora 28

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: valgrind issues on Fedora 28
Date: 2019-01-07 23:54:04
Message-ID: 21c39c42-061d-e31e-143b-ccda1a19f8e1@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/15/18 12:32 AM, Andrew Dunstan wrote:
>
> On 12/14/18 4:35 PM, Tomas Vondra wrote:
>> On 12/14/18 4:58 PM, Tom Lane wrote:
>>> ...
>>>
>>> In general, I'm not particularly on board with our valgrind.supp
>>> carrying suppressions for code outside our own code base: I think
>>> that's assuming WAY too much about which version of what is installed
>>> on a particular box.
>>>
>> Fair point.
>>
>>> Maybe we could do something to make it simpler to have custom
>>> suppressions? Not sure what, though.
>>>
>> I was thinking that perhaps we could allows specifying path to extra
>> suppressions and pass that to valgrind.
>>
>> But we don't actually invoke valgrind, that's something people do on
>> their own anyway - so we don't have anywhere to pass the path to. And
>> whoever invokes valgrind can simply stick it directly into the command
>> they're using (as it allows specifying multiple --suppressions=<file>
>> options). Or perhaps just put it into ~/.valgrindrc.
>>
>> So perhaps we should simply revert that commit and be done with it.
>>
>> One place that will need to solve it is buildfarm client, but it could
>> pick either of the options I mentioned.
>>
>>
>
> The buildfarm client has a parameter in the config file for valgrind
> options. All you would have to do is an an extra --suppressions setting
> in there.
>

OK, makes sense. I'll revert the commit tomorrow.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-01-07 23:55:54 Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name
Previous Message Andres Freund 2019-01-07 22:12:04 Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)