| From: | Andres Freund <andres(at)anarazel(dot)de> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org | 
| Subject: | Re: Non-reproducible valgrind failure on HEAD | 
| Date: | 2021-05-09 21:02:55 | 
| Message-ID: | 20210509210255.h5vhmieswhcsiqcq@alap3.anarazel.de | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Hi,
On 2021-05-09 15:29:06 -0400, Tom Lane wrote:
> I happened to be trying to run the core regression tests under
> valgrind, and I got the complaints attached below, from the
> process that had been running the insert_conflict test script.
>
> I could not reproduce the failure in a second run, which is not
> hugely surprising because it appears to be in cross-process
> sinval processing; so timing sensitivity is to be expected.
> That doesn't make it any less disturbing.
>
> One point worth mentioning is that I'd forgotten to build with
> "#define USE_VALGRIND" in the first try.  AFAIK that should make
> valgrind strictly less sensitive, so I think it's not material,
> but still.
I think it may be material - see the comments in
AddCatcacheInvalidationMessage(). Valgrind doesn't cope correctly with
the sinval ringbuffer being accessed in multiple processes. If process A
adds an invalidation to position 0 and then later processes another
invalidation at the same position 0 that was added by B, valgrind will
use the "is defined" state from the invalidation it queued itself, not
the one that B queued.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-05-09 21:12:14 | Re: Non-reproducible valgrind failure on HEAD | 
| Previous Message | Alexander Korotkov | 2021-05-09 20:17:47 | Re: JSON doc example (matchiness) |