Re: pgsql: Add parallel-aware hash joins. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgsql: Add parallel-aware hash joins.
Date
Msg-id 25496.1515096975@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Add parallel-aware hash joins.  (Andres Freund <andres@anarazel.de>)
Responses Re: pgsql: Add parallel-aware hash joins.
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2018-01-04 11:20:33 -0800, Andres Freund wrote:
>> Some packages on skink have been upgraded. It appears that there either
>> was a libc or valgrind change that made valgrind not recognize that a
>> pointer of 0 might not point anywhere :(

> ==5718== Invalid write of size 8
> ==5718==    at 0x40E3DD: ExecInterpExpr (execExprInterp.c:1117)
> ==5718==    by 0x40F5E9: ExecInterpExprStillValid (execExprInterp.c:1788)
> ==5718==    by 0xE6B0409: ExecEvalExpr (executor.h:282)

Are those line numbers supposed to match current HEAD?  1117 does not
contain any write AFAICS:

    if (!op->d.iocoerce.finfo_in->fn_strict || str != NULL)

> ==5718== Process terminating with default action of signal 11 (SIGSEGV)
> ==5718==  Access not within mapped region at address 0x20
> ==5718==    at 0x40E3DD: ExecInterpExpr (execExprInterp.c:1117)
> ==5718==    by 0x40F5E9: ExecInterpExprStillValid (execExprInterp.c:1788)

This would be consistent with op->d.iocoerce.finfo_in being NULL, I think,
but there is no way that execExpr.c could have created an EEOP_IOCOERCE
step without filling in the finfo_in pointer.

I think the correct conclusion is that this version of valgrind is
buggy as hell.  I wouldn't clutter our code with suppressions trying
to make it sort-of work.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pgsql: Add parallel-aware hash joins.
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Finalizing logical replication limitations as well as potentialfeatures