Cooperate with the Valgrind instrumentation framework.

Valgrind "client requests" in aset.c and mcxt.c teach Valgrind and its
Memcheck tool about the PostgreSQL allocator.  This makes Valgrind
roughly as sensitive to memory errors involving palloc chunks as it is
to memory errors involving malloc chunks.  Further client requests in
PageAddItem() and printtup() verify that all bits being added to a
buffer page or furnished to an output function are predictably-defined.
Those tests catch failures of C-language functions to fully initialize
the bits of a Datum, which in turn stymie optimizations that rely on
_equalConst().  Define the USE_VALGRIND symbol in pg_config_manual.h to
enable these additions.  An included "suppression file" silences nominal
errors we don't plan to fix.

Reviewed in earlier versions by Peter Geoghegan and Korry Douglas.

Author: nmisch

src/backend/access/common/printtup.c

@@ -20,6 +20,7 @@
 #include "libpq/pqformat.h"
 #include "tcop/pquery.h"
 #include "utils/lsyscache.h"
+#include "utils/memdebug.h"
 
 
 static void printtup_startup(DestReceiver *self, int operation,
@@ -324,9 +325,26 @@ printtup(TupleTableSlot *slot, DestReceiver *self)
 		/*
 		 * If we have a toasted datum, forcibly detoast it here to avoid
 		 * memory leakage inside the type's output routine.
+		 *
+		 * Here we catch undefined bytes in tuples that are returned to the
+		 * client without hitting disk; see comments at the related check in
+		 * PageAddItem().  Whether to test before or after detoast is somewhat
+		 * arbitrary, as is whether to test external/compressed data at all.
+		 * Undefined bytes in the pre-toast datum will have triggered Valgrind
+		 * errors in the compressor or toaster; any error detected here for
+		 * such datums would indicate an (unlikely) bug in a type-independent
+		 * facility.  Therefore, this test is most useful for uncompressed,
+		 * non-external datums.
+		 *
+		 * We don't presently bother checking non-varlena datums for undefined
+		 * data.  PageAddItem() does check them.
 		 */
 		if (thisState->typisvarlena)
+		{
+			VALGRIND_CHECK_MEM_IS_DEFINED(origattr, VARSIZE_ANY(origattr));
+
 			attr = PointerGetDatum(PG_DETOAST_DATUM(origattr));
+		}
 		else
 			attr = origattr;
 

src/backend/storage/page/bufpage.c

@@ -17,6 +17,7 @@
 #include "access/htup_details.h"
 #include "access/xlog.h"
 #include "storage/checksum.h"
+#include "utils/memdebug.h"
 #include "utils/memutils.h"
 
 
@@ -297,6 +298,20 @@ PageAddItem(Page page,
 	/* set the item pointer */
 	ItemIdSetNormal(itemId, upper, size);
 
+	/*
+	 * Items normally contain no uninitialized bytes.  Core bufpage consumers
+	 * conform, but this is not a necessary coding rule; a new index AM could
+	 * opt to depart from it.  However, data type input functions and other
+	 * C-language functions that synthesize datums should initialize all
+	 * bytes; datumIsEqual() relies on this.  Testing here, along with the
+	 * similar check in printtup(), helps to catch such mistakes.
+	 *
+	 * Values of the "name" type retrieved via index-only scans may contain
+	 * uninitialized bytes; see comment in btrescan().  Valgrind will report
+	 * this as an error, but it is safe to ignore.
+	 */
+	VALGRIND_CHECK_MEM_IS_DEFINED(item, size);
+
 	/* copy the item's data onto the page */
 	memcpy((char *) page + upper, item, size);
 

src/backend/tcop/postgres.c

@@ -69,6 +69,7 @@
 #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,6 +847,10 @@ exec_simple_query(const char *query_string)
 
 	TRACE_POSTGRESQL_QUERY_START(query_string);
 
+#ifdef USE_VALGRIND
+	VALGRIND_PRINTF("statement: %s\n", query_string);
+#endif
+
 	/*
 	 * We use save_log_statement_stats so ShowUsage doesn't report incorrect
 	 * results because ResetUsage wasn't called.