On 03/26/2017 08:47 PM, Andres Freund wrote:
> On 2017-03-26 20:38:52 +0200, Tomas Vondra wrote:
>> ...
>> Hmmm, so I have a theory about what's going on, but no matter what I do I
>> can't trigger these valgrind failures. What switches are you using to start
>> valgrind? I'm using this:
>>
>> valgrind --leak-check=no --undef-value-errors=yes \
>> --expensive-definedness-checks=yes --track-origins=yes \
>> --read-var-info=yes --gen-suppressions=all \
>> --suppressions=src/tools/valgrind.supp --time-stamp=yes \
>> --log-file=$HOME/pg-valgrind/%p.log --trace-children=yes \
>> postgres --log_line_prefix="%m %p " --log_statement=all \
>> --shared_buffers=64MB -D /home/user/tmp/data-valgrind 2>&1
>
> --quiet \
> --error-exitcode=55 \
> --suppressions=${PG_SRC_DIR}/src/tools/valgrind.supp \
> --trace-children=yes --track-origins=yes --read-var-info=yes \
> --num-callers=20 \
> --leak-check=no \
> --gen-suppressions=all \
>
> the error-exitcode makes it a whole lot easier to see an error, because
> it triggers a crash-restart cycle at backend exit ;)
>
OK, this did the trick. And just as I suspected, it seems to be due to
doing memcpy+offsetof when serializing the statistic into a bytea. The
attached patch fixes that for me. Can you test it on your build?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
