Re: Non-reproducible valgrind failure on HEAD

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.
  */