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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Valgrind Memcheck support
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: pg_dump/restore encoding woes