Date: Thu, 4 Jan 2018 12:47:41 -0800
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Thomas Munro <thomas.munro@enterprisedb.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: pgsql: Add parallel-aware hash joins.
Message-ID: <20180104204741.ghg2yr4is4flbuhn@alap3.anarazel.de>
References: 
 <CAEepm=34PDuR69kfYVhmZPgMdy8pSA-MYbpesEN1SR+2oj3Y+w@mail.gmail.com>
 <5187.1515028624@sss.pgh.p!a.us>
 <CAEepm=1uuT8iJxMEsR=jL+3zEi87DB2v0+0H9o_rUXXCZPZT3A@mail.gmail.com>
 <16320.1515046173@sss.pgh.pa.us>
 <4847.1515081624@sss.pgh.pa.us>
 <CA+TgmoY7JAxRW_UQZAyxH3=JXV3WTFdwfTdyGB3TySj7c1i2yg@mail.gmail.com>
 <7839.1515085897@sss.pgh.pa.us>
 <20180104192033.irv4ppf44i2fesze@alap3.anarazel.de>
 <20180104200647.wna6yoin7nav5qqo@alap3.anarazel.de>
 <25496.1515096975@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <25496.1515096975@sss.pgh.pa.us>
Precedence: bulk

On 2018-01-04 15:16:15 -0500, Tom Lane wrote:
> 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?

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