Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHzKV-0003av-Qg for pgsql-committers@arkaria.postgresql.org; Thu, 23 Nov 2017 21:46:44 +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 1eHzKV-0004Zh-2v for pgsql-committers@arkaria.postgresql.org; Thu, 23 Nov 2017 21:46:43 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eHzKU-0004ZX-D3 for pgsql-committers@lists.postgresql.org; Thu, 23 Nov 2017 21:46:42 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eHzKR-0005yC-3K for pgsql-committers@postgresql.org; Thu, 23 Nov 2017 21:46:41 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D362D20716; Thu, 23 Nov 2017 16:46:37 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 23 Nov 2017 16:46:37 -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=ajlqjYUw/XuygS3ireLKtkp2fo1TA 9B2YBfBadZn8DM=; b=Jd7wBXYXftqk25bjjSvbp026BjZbqTrm4NxhsAT4ro3kr WyBLS4OaHYXhjXQCoXr44h7sKQDBJc0yi6g3BInsDOL4iH75OlqbGpQpq5BEVzsP 4nFxSfRxBcYnWk6C+9Wr33nnsTXnB0ox1o8PeSEbh4HyUR/dsu8ba1/aCOrHQYc1 iySvd5+snUjrIaIuo0cgdGSsvNQ05PPHiNf2rtaGh8DLptGp/KJ63oiJS+4ZIhKp SpiCgsyvViEXh8efMfzJirSlF3pzLId8pAT3+bbSUT7vmjoLDX6jQvLCkFAsQYSy vCIZ8g0+brCFZQ5oGiKTdx3Zu6ELLWnU0zdUmXA/w== X-ME-Sender: Received: from intern.anarazel.de (unknown [136.24.76.189]) by mail.messagingengine.com (Postfix) with ESMTPA id 8C70024009; Thu, 23 Nov 2017 16:46:37 -0500 (EST) Date: Thu, 23 Nov 2017 13:46:36 -0800 From: Andres Freund To: Tomas Vondra Cc: Tom Lane , Simon Riggs , pgsql-committers , Andrew Dunstan Subject: Re: pgsql: Generational memory allocator Message-ID: <20171123214636.unwkrkunr7m2bkii@alap3.anarazel.de> References: <20171123001649.y2nf7422iay6cw3v@alap3.anarazel.de> <20171123193936.fncfnar5wkpx56mw@alap3.anarazel.de> <21043.1511467602@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2017-11-23 22:34:57 +0100, Tomas Vondra wrote: > > I think it's a legitimate complaint that postmaster.log wasn't captured > > in this failure, but that's a buildfarm script oversight and hardly > > Andres' fault. > > > > Are the valgrind errors really written to postmaster log? I'm assuming it > failed because valgrind ran into an issue and killed the process. Yes. Search e.g. in https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2017-09-18%2004%3A10%3A01 for VALGRINDERROR-BEGIN. (You could argue that they're only written there in certain configurations, because I'd assume it'd not work in e.g. syslog configured systems, because valgrind just prints to stderr). > Hmmm, I see. Presumably adding this to GenerationChunk (similarly to what we > do in AllocChunkData) would address the issue: > > #if MAXIMUM_ALIGNOF > 4 && SIZEOF_VOID_P == 4 > Size padding; > #endif > > but I have no way to verify that (no access to such machine). I wonder why > SlabChunk doesn't need to do that (perhaps a comment explaining that would > be appropriate?). Can't you just compile pg on a 32bit system and manually define MAXALIGN to 8 bytes? Greetings, Andres Freund