Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kW4Uv-0000qd-8R for pgsql-hackers@arkaria.postgresql.org; Fri, 23 Oct 2020 21:21:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kW4Ut-0003aT-MC for pgsql-hackers@arkaria.postgresql.org; Fri, 23 Oct 2020 21:21:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kW4Ut-0003aM-FG for pgsql-hackers@lists.postgresql.org; Fri, 23 Oct 2020 21:21:15 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kW4Ur-0001MJ-DS for pgsql-hackers@postgresql.org; Fri, 23 Oct 2020 21:21:14 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 09NLKxD2271247; Fri, 23 Oct 2020 17:20:59 -0400 From: Tom Lane To: Mark Dilger cc: Robert Haas , Peter Geoghegan , "Andrey M. Borodin" , Stephen Frost , Michael Paquier , Amul Sul , Dilip Kumar , Andres Freund , PostgreSQL-development Subject: Re: new heapcheck contrib module In-reply-to: References: <12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com> <20200420194210.sevnpi4lyghoanxi@alap3.anarazel.de> <23E60C3C-C20A-4508-84AC-E0CEA59E784A@enterprisedb.com> <5F743835-3399-419C-8324-2D424237E999@enterprisedb.com> <885D2EC9-7D06-4903-A17D-72C184A1E1C5@enterprisedb.com> <5CC85F28-F210-47AC-8DA8-EC4E82AF3FD5@enterprisedb.com> <0C0349EB-DD85-4DA8-82C7-DF70AB714592@enterprisedb.com> <9DF93B83-FE46-4EC4-A99D-77A60729FD2D@enterprisedb.com> <50F6468F-5A5E-412A-86EC-DF24B549D733@enterprisedb.com> <7D603B53-8078-4AF0-851B-803FF4416501@enterprisedb.com> <98265AA9-7BDC-4708-9348-CC1B173BBE1D@enterprisedb.com> <209783.1603313248@sss.pgh.pa.us> <77A60E99-6054-40FD-A5D6-769C287D4A0F@enterprisedb.co! m> <721BFA83-EA6F-463D-A9DF-CE78A318B73A@enterprisedb.com> <2A7DA1A8-C4AA-43DF-A985-3CA52F4DC775@enterprisedb.com> << message dated "Fri, 23 Oct 2020 13:52:18 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <271245.1603488059.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Oct 2020 17:20:59 -0400 Message-ID: <271246.1603488059@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Mark Dilger writes: >> On Oct 23, 2020, at 11:51 AM, Tom Lane wrote: >> I do not have 64-bit big-endian hardware to play with unfortunately. >> But what I suspect is happening here is less about endianness and >> more about alignment pickiness; or maybe we were unlucky enough to >> index off the end of the shmem segment. > You certainly appear to be right about that. I've added the extra check= s, and extended the regression test to include them. Patch attached. Meanwhile, I've replicated the SIGBUS problem on gaur's host, so that's definitely what's happening. (Although PPC is also alignment-picky on the hardware level, I believe that both macOS and Linux try to mask that by having kernel trap handlers execute unaligned accesses, leaving only a nasty performance loss behind. That's why I failed to see this effect when checking your previous patch on an old Apple box. We likely won't see it in the buildfarm either, unless maybe on Noah's AIX menagerie.) I'll check this patch on gaur and push it if it's clean. regards, tom lane