Re: PostgreSQL crashes with SIGSEGV
От | Bernd Helmle |
---|---|
Тема | Re: PostgreSQL crashes with SIGSEGV |
Дата | |
Msg-id | 1512724784.9720.39.camel@oopsware.de обсуждение исходный текст |
Ответ на | Re: PostgreSQL crashes with SIGSEGV (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: PostgreSQL crashes with SIGSEGV
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: