Re: Valgrind Memcheck support - Mailing list pgsql-hackers

From Atri Sharma
Subject Re: Valgrind Memcheck support
Date
Msg-id 1E7585A0-E1E9-4D68-B591-3E29D55BDC79@gmail.com
Whole thread Raw
In response to Re: Valgrind Memcheck support  (Andres Freund <andres@2ndquadrant.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Valgrind Memcheck support
Next
From: Heikki Linnakangas
Date:
Subject: Re: pg_dump/restore encoding woes