Andres Freund <andres@anarazel.de> writes:
> On 2021-05-09 17:12:14 -0400, Tom Lane wrote:
>> (I wonder if we shouldn't adjust the comments in pg_config_manual.h,
>> though, as they certainly leave the impression that USE_VALGRIND
>> isn't essential.)
> That'd make sense to me. If we found a better way to deal with the
> sinval thing it'd be good too - but I am not seeing anything convincing,
> and I looked a couple times over the years...
Yeah, it's actually somewhat amazing that we get useful results at all
around shared-memory accesses.
Proposed comment patch attached.
regards, tom lane
diff --git a/src/include/pg_config_manual.h b/src/include/pg_config_manual.h
index e28c990382..42ee43f0aa 100644
--- a/src/include/pg_config_manual.h
+++ b/src/include/pg_config_manual.h
@@ -279,12 +279,18 @@
* enables detection of buffer accesses that take place without holding a
* buffer pin (or without holding a buffer lock in the case of index access
* methods that superimpose their own custom client requests on top of the
- * generic bufmgr.c requests). See also src/tools/valgrind.supp.
+ * generic bufmgr.c requests).
*
* "make installcheck" is significantly slower under Valgrind. The client
* requests fall in hot code paths, so USE_VALGRIND slows execution by a few
* percentage points even when not run under Valgrind.
*
+ * Do not try to test the server under Valgrind without having built the
+ * server with USE_VALGRIND; else you will get false positives from sinval
+ * messaging (see comments in AddCatcacheInvalidationMessage). It's also
+ * important to use the suppression file src/tools/valgrind.supp to
+ * exclude other known false positives.
+ *
* You should normally use MEMORY_CONTEXT_CHECKING with USE_VALGRIND;
* instrumentation of repalloc() is inferior without it.
*/