Re: pgsql: Add parallel-aware hash joins.
От | Tom Lane |
---|---|
Тема | Re: pgsql: Add parallel-aware hash joins. |
Дата | |
Msg-id | 25496.1515096975@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Add parallel-aware hash joins. (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: pgsql: Add parallel-aware hash joins.
|
Список | 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 по дате отправления: