On 11/7/18 9:30 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 11/7/18 7:26 AM, Jesper Pedersen wrote:
>>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2018-11-07%2001%3A01%3A01
>> And lousyjack, which uses a slightly different way of calling valgrind,
>> and thus got past initdb, found a bunch more:
>> <https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lousyjack&dt=2018-11-07%2001%3A33%3A01>
> I'm confused by this. Surely the pwrite-based code is writing exactly the
> same data as before. Do we have to conclude that valgrind is complaining
> about passing uninitialized data to pwrite() when it did not complain
> about exactly the same thing for write()?
>
> [ looks ... ] No, what we have to conclude is that the write-related
> suppressions in src/tools/valgrind.supp need to be replaced or augmented
> with pwrite-related ones.
Yeah. I just trawled through the lousyjack logs and it looks like all
the cases it reported could be handled by:
{
padding_XLogRecData_pwrite
Memcheck:Param
pwrite64(buf)
...
fun:XLogWrite
}
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services