Re: pgsql: Add parallel-aware hash joins.

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Add parallel-aware hash joins.
Date: 2018-01-04 20:47:41
Message-ID: 20180104204741.ghg2yr4is4flbuhn@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On 2018-01-04 15:16:15 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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?

Well, 3e68686e2c55799234ecd020bd1621f913d65475, but that's pretty
close.

But I think it was just the result of a somehow not entirely clean
build, with plpgsql not being rebuilt when necessary. Not sure why/how,
but at least that means the epoll_pwait() suppression likely revive
skink to some degree.

I made sure that the valgrind version isn't affected (from mid last
year). After a forced rebuild survives a bit longer, but also encounters

==13750== Conditional jump or move depends on uninitialised value(s)
==13750== at 0x6BA888C: __wcsnlen_avx2 (strlen-avx2.S:103)
==13750== by 0x6AF2FF1: wcsrtombs (wcsrtombs.c:104)
==13750== by 0x6A88A40: wcstombs (wcstombs.c:34)
==13750== by 0x6BA76C: wchar2char (pg_locale.c:1641)
==13750== by 0x653A7C: str_tolower (formatting.c:1591)

and various other related issues. I'm not sure if there's a legitimate
formatting.c issue or whether it's glibc changes around string handling
triggering spurious blurbs.

Greetings,

Andres Freund

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2018-01-04 20:55:06 pgsql: Simplify and encapsulate tuple routing support code.
Previous Message Peter Eisentraut 2018-01-04 20:36:41 pgsql: Implement channel binding tls-server-end-point for SCRAM

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-01-04 20:54:47 Re: Condition variable live lock
Previous Message Peter Eisentraut 2018-01-04 20:41:39 Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256