Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On 12/14/18 5:10 AM, Tom Lane wrote:
>> So I just got around to trying to do some valgrind testing for the first
>> time in a couple of months, and what I find is that this patch completely
>> breaks valgrind for me ...
>> This is valgrind 3.8.1 (RHEL6's version), so not bleeding edge exactly,
>> but we have very little evidence about how far back the committed patch
>> works. I'm inclined to think we can't use this solution.
> Fedora 28 has 3.14.0, so this seems to be due to some improvements since
> 3.8.1. I'm not sure how to deal with this - surely we don't want to just
> revert the change because that would start generating noise again. For a
> moment I thought we might wildcard the error type somehow, so that it
> would accept Memcheck:* but AFAICs that is not supported.
Meh. There are lots of situations where it's necessary to carry some
platform-specific valgrind suppressions; I have half a dozen on my
RHEL6 box because of various weirdness in its old version of perl, for
example. I think this is one where people running code new enough to
have this problem need to carry private suppressions of their own.
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.
Maybe we could do something to make it simpler to have custom
suppressions? Not sure what, though.
regards, tom lane
