Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXB4K-0002Iq-Je for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jan 2018 19:20:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXB4J-0000j5-Vp for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jan 2018 19:20:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eXB4A-0007aQ-RE for pgsql-hackers@lists.postgresql.org; Thu, 04 Jan 2018 19:20:38 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eXB47-0003I1-Ga for pgsql-hackers@postgresql.org; Thu, 04 Jan 2018 19:20:37 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 4326F20C87; Thu, 4 Jan 2018 14:20:34 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 04 Jan 2018 14:20:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=0lJHoC4/6urb3b9jJZ6WnPTnZKqqp bO6w2KyzIXfRDA=; b=pM90Y/KiYW1UOJTsdWZcSCd855/Wh1C86w4adgXLZYIcj G6FmYPKvLZjvmcsHJNlm4376DI1G2huV+6bqU0MAva//MvRzlHuSGX0WRvMvSFIz 9VjUInT2yVK4kuWr1gSGCqDiRsOFsBKrefDvMlSJ2F6t0dJnezDvATJxpGS9fTRf XfcGCSJ52vCJzleawTqX/FIPvrgmVSFOn8rsx1mocm8Or29VfADn3XE/C/NPH5zj bzaIWHtkI9UXonSAlxTMX66Z9R22A89C6UlOskHEJQeg3ZdqEfsALbr45IrotaE1 /ZMiFoaNXFhGN29kNCjiic3nn869QuETKHmdCrPzg== X-ME-Sender: Received: from intern.anarazel.de (unknown [136.24.76.189]) by mail.messagingengine.com (Postfix) with ESMTPA id 0B9E27E34D; Thu, 4 Jan 2018 14:20:34 -0500 (EST) Date: Thu, 4 Jan 2018 11:20:33 -0800 From: Andres Freund To: Tom Lane Cc: Robert Haas , Thomas Munro , "pgsql-hackers@postgresql.org" Subject: Re: pgsql: Add parallel-aware hash joins. Message-ID: <20180104192033.irv4ppf44i2fesze@alap3.anarazel.de> References: <4001.1514678419@sss.pgh.pa.us> <18190.1514943510@sss.pgh.pa.us> <5187.1515028624@sss.pgh.p!a.us> <16320.1515046173@sss.pgh.pa.us> <4847.1515081624@sss.pgh.pa.us> <7839.1515085897@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7839.1515085897@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2018-01-04 12:11:37 -0500, Tom Lane wrote: > Robert Haas writes: > > On Thu, Jan 4, 2018 at 11:00 AM, Tom Lane wrote: > >> Also, what the devil is happening on skink? > > > So, skink is apparently dying during shutdown of a user-connected > > backend, and specifically the one that executed the 'tablespace' test. > > Well, yeah, valgrind is burping: the postmaster log is full of > > ==10544== VALGRINDERROR-BEGIN > ==10544== Syscall param epoll_pwait(sigmask) points to unaddressable byte(s) > ==10544== at 0x7011490: epoll_pwait (epoll_pwait.c:42) > ==10544== by 0x4BF40B: WaitEventSetWaitBlock (latch.c:1048) > ==10544== by 0x4BF40B: WaitEventSetWait (latch.c:1000) > ==10544== by 0x3C0B3B: secure_read (be-secure.c:166) > ==10544== by 0x3CCD9E: pq_recvbuf (pqcomm.c:963) > ==10544== by 0x3CDA07: pq_getbyte (pqcomm.c:1006) > ==10544== by 0x4E2A2D: SocketBackend (postgres.c:339) > ==10544== by 0x4E444E: ReadCommand (postgres.c:512) > ==10544== by 0x4E7588: PostgresMain (postgres.c:4085) > ==10544== by 0x4641D0: BackendRun (postmaster.c:4412) > ==10544== by 0x467308: BackendStartup (postmaster.c:4084) > ==10544== by 0x4675F7: ServerLoop (postmaster.c:1757) > ==10544== by 0x4689D4: PostmasterMain (postmaster.c:1365) > ==10544== Address 0x0 is not stack'd, malloc'd or (recently) free'd > ==10544== > ==10544== VALGRINDERROR-END > > But (a) this is happening in multiple branches, and (b) we've not > changed anything near that code in awhile. I think something broke > in valgrind itself. 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 :( Let me check whether valgrind accept multiple suppression files, in which case I could add a suppression for this error to all branches. Will also check whether I can reproduce locally. Greetings, Andres Freund