Horton

Thread

Commits

  1. Improve comments about USE_VALGRIND in pg_config_manual.h.

  1. Non-reproducible valgrind failure on HEAD

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-05-09T19:29:06Z

    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.

Thoughts?

			regards, tom lane

  2. Re: Non-reproducible valgrind failure on HEAD

    Andres Freund <andres@anarazel.de> — 2021-05-09T21:02:55Z

    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

  3. Re: Non-reproducible valgrind failure on HEAD

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-05-09T21:12:14Z

    Andres Freund <andres@anarazel.de> writes:
> On 2021-05-09 15:29:06 -0400, Tom Lane wrote:
>> 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().

Ah-hah.  Please excuse the noise.

(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.)

			regards, tom lane

  4. Re: Non-reproducible valgrind failure on HEAD

    Andres Freund <andres@anarazel.de> — 2021-05-09T21:17:50Z

    Hi,

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

  5. Re: Non-reproducible valgrind failure on HEAD

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-05-09T22:17:36Z

    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

  6. Re: Non-reproducible valgrind failure on HEAD

    Andres Freund <andres@anarazel.de> — 2021-05-09T22:40:06Z

    On 2021-05-09 18:17:36 -0400, Tom Lane wrote:
> Proposed comment patch attached.

lgtm.

  7. Re: Non-reproducible valgrind failure on HEAD

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-05-09T23:36:16Z

    Andres Freund <andres@anarazel.de> writes:
> On 2021-05-09 18:17:36 -0400, Tom Lane wrote:
>> Proposed comment patch attached.

> lgtm.

Pushed, thanks.

			regards, tom lane