Re: Valgrind Memcheck support
От | Andres Freund |
---|---|
Тема | Re: Valgrind Memcheck support |
Дата | |
Msg-id | 20130827141427.GF24807@alap2.anarazel.de обсуждение исходный текст |
Ответ на | Valgrind Memcheck support (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Valgrind Memcheck support
Re: Valgrind Memcheck support |
Список | pgsql-hackers |
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? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: