Re: Valgrind Memcheck support
От | Atri Sharma |
---|---|
Тема | Re: Valgrind Memcheck support |
Дата | |
Msg-id | 1E7585A0-E1E9-4D68-B591-3E29D55BDC79@gmail.com обсуждение исходный текст |
Ответ на | Re: Valgrind Memcheck support (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
Sent from my iPad On 27-Aug-2013, at 19:44, Andres Freund <andres@2ndquadrant.com> wrote: > Hi Noah, > > On 2013-06-09 17:25:59 -0400, Noah Misch wrote: >> *** a/src/backend/tcop/postgres.c >> --- b/src/backend/tcop/postgres.c >> *************** >> *** 69,74 **** >> --- 69,75 ---- >> #include "tcop/tcopprot.h" >> #include "tcop/utility.h" >> #include "utils/lsyscache.h" >> + #include "utils/memdebug.h" >> #include "utils/memutils.h" >> #include "utils/ps_status.h" >> #include "utils/snapmgr.h" >> *************** >> *** 846,851 **** exec_simple_query(const char *query_string) >> --- 847,856 ---- >> >> TRACE_POSTGRESQL_QUERY_START(query_string); >> >> + #ifdef USE_VALGRIND >> + VALGRIND_PRINTF("statement: %s\n", query_string); >> + #endif >> + > > Is there a special reason for adding more logging here? I find this > makes the instrumentation much less useful since reports easily get > burried in those traces. What's the advantage of doing this instead of > log_statement=...? Especially as that location afaics won't help for the > extended protocol? > > +1. I also feel that extra traces may tend to confuse up the actual hot spot. Extra debugging can be happily be done withhigher log levels. Regards, Atri
В списке pgsql-hackers по дате отправления: