Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eDZrE-0004jE-4y for pgsql-bugs@arkaria.postgresql.org; Sat, 11 Nov 2017 17:46:16 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1eDZrD-00021H-NZ for pgsql-bugs@arkaria.postgresql.org; Sat, 11 Nov 2017 17:46:15 +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 1eDZqM-0007ap-Hl for pgsql-bugs@postgresql.org; Sat, 11 Nov 2017 17:45:22 +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 1eDZqF-0007tz-0O for pgsql-bugs@postgresql.org; Sat, 11 Nov 2017 17:45:21 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 1B5A420B87; Sat, 11 Nov 2017 12:45:14 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Sat, 11 Nov 2017 12:45:14 -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=yUnlyTwEPK9Avl5Ef3JNImc/SjTZI y2kgm+MXjpcnGw=; b=iDnPYtSlKM7rbp0AO3cdwwN1QnS2zQBBLM1d+cWH1Azya iSulOWdrMMEmfidWUj5R9KKDJvdtMtLYGSlZGrcp7nf2irm/uNiK+MEtCMgOn/Nd vpKic3Q6fuKRu7qcF+EMZOsji8+l797074vZC+spU1G3AXiVMDqt6CA7z6g3/KEt nGcJ11k6rAoKbiuq3D0BDxmPyUof4sG4V2WFp3siIa5otfaFH+tZ6yZ9SB/VcIv9 MflyKn9oYSoeLZlVmpSvUZ73OzoiEwu7ysD5ZYo0hyMU3N7aFpU9qWwtGgEKisUu EZDtgHNn5R4VFnvQfTEePf0+0VfKZHsqnwEkC9+Kw== X-ME-Sender: Received: from intern.anarazel.de (unknown [136.24.76.189]) by mail.messagingengine.com (Postfix) with ESMTPA id D12D3240F8; Sat, 11 Nov 2017 12:45:13 -0500 (EST) Date: Sat, 11 Nov 2017 09:45:12 -0800 From: Andres Freund To: Tom Lane Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Michael Paquier , Vincent Lachenal , PostgreSQL mailing lists Subject: Re: BUG #14897: Segfault on statitics SQL request Message-ID: <20171111174512.ikd3zrx2i5ssxpww@alap3.anarazel.de> References: <14075.1510352167@sss.pgh.pa.us> <17617.1510355215@sss.pgh.pa.us> <644.1510418216@sss.pgh.pa.us> <20171111171620.td6vtnmijcloj6k5@alap3.anarazel.de> <3914.1510422100@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3914.1510422100@sss.pgh.pa.us> List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-bugs Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org On 2017-11-11 12:41:40 -0500, Tom Lane wrote: > Andres Freund writes: > > That's using SSE, which requires 16byte alignment IIRC. I think we need > > a function that properly allocate int128 vars with the right alignment - > > don't think we want to go for full 16byte alignment for everything. > > Yeah, changing MAXALIGN is out of the question. I'm thinking about > another flag bit for MemoryContextAllocExtended. Do we need to think > about other use-cases besides int128? Should we just force 16-byte > alignment on all architectures, or does it need to be platform-specific? I'm not sure we want to a) Rely on one alignment being enough for everybody. b) Additionally burden already hot code paths with a growing number of alignment flag tests, and the necessary math. How about a MemoryContextAllocAligned(context, size, alignto, flags) that passes on most flags but adds the necessary overhead to size, and padds the result appropriately? Greetings, Andres Freund -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs