Am Donnerstag, den 07.12.2017, 18:54 -0800 schrieb Peter Geoghegan:
> So, as you said, the question that we probably need to answer is:
> just
> how did grouping sets/nodeAgg.c code end up getting tuple memory
> lifetime wrong. One good way to get more information is to rerun
> Valgrind, but this time with track origins enabled. I myself run
> Valgrind like this when I want to see the origin of memory involved
> in
> an error. I specify:
>
> $ valgrind --leak-check=no --gen-suppressions=all --trace-
> children=yes
> --track-origins=yes --read-var-info=yes
> --
> suppressions=/home/pg/postgresql/root/source/src/tools/valgrind.supp
> -v postgres --log_line_prefix="%m %p " --log_statement=all
> --shared_buffers=64MB 2>&1 | tee postmaster.log
>
> (Probably the only change that you'll need is to make is to run
> Valgrind with an the extra "--track-origins=yes".)
>
> --track-origins=yes is usually something I use when I already know
> that Valgrind will complain, but want more information about the
> nature of the problem.
That's what i've already did. My usage of valgrind was this:
valgrind --leak-check=no --gen-suppressions=all \
--track-origins=yes --suppressions=src/tools/valgrind.supp \
--time-stamp=yes --trace-children=yes postgres
