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  (Atri Sharma <atri.jiit@gmail.com>)
Re: Valgrind Memcheck support  (Noah Misch <noah@leadboat.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Support for REINDEX CONCURRENTLY
Следующее
От: Atri Sharma
Дата:
Сообщение: Re: Valgrind Memcheck support