Re: Valgrind Memcheck support - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Valgrind Memcheck support
Date
Msg-id 20130827141427.GF24807@alap2.anarazel.de
Whole thread Raw
In response to Valgrind Memcheck support  (Noah Misch <noah@leadboat.com>)
Responses Re: Valgrind Memcheck support  (Atri Sharma <atri.jiit@gmail.com>)
Re: Valgrind Memcheck support  (Noah Misch <noah@leadboat.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Support for REINDEX CONCURRENTLY
Next
From: Atri Sharma
Date:
Subject: Re: Valgrind Memcheck support