On 11/7/18 9:30 AM, Tom Lane wrote:
Andrew Dunstan <andrew.duns...@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


Reply via email to