Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rb9EM-00DbjE-JT for pgsql-hackers@arkaria.postgresql.org; Sat, 17 Feb 2024 01:11:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rb9EI-005Zya-Py for pgsql-hackers@arkaria.postgresql.org; Sat, 17 Feb 2024 01:10:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rb9EI-005ZyR-GU for pgsql-hackers@lists.postgresql.org; Sat, 17 Feb 2024 01:10:58 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rb9EB-0078V0-JN for pgsql-hackers@lists.postgresql.org; Sat, 17 Feb 2024 01:10:57 +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 41H1Amn73551158; Fri, 16 Feb 2024 20:10:48 -0500 From: Tom Lane To: Tomas Vondra cc: Matthias van de Meent , David Rowley , PostgreSQL Developers Subject: Re: Add bump memory context type and use it for tuplesorts In-reply-to: References: <3537323.1708125284@sss.pgh.pa.us> Comments: In-reply-to Tomas Vondra message dated "Sat, 17 Feb 2024 01:31:07 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3551156.1708132248.1@sss.pgh.pa.us> Date: Fri, 16 Feb 2024 20:10:48 -0500 Message-ID: <3551157.1708132248@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Tomas Vondra writes: > On 2/17/24 00:14, Tom Lane wrote: >> The conclusion was that the specific invalid values didn't matter as >> much on the other platforms as they do with glibc. But right now you >> have a fifty-fifty chance that a pointer to garbage will look valid. >> Do we want to increase those odds? > Not sure. The ability to detect bogus pointers seems valuable, but is > the difference between 4/8 and 3/8 really qualitatively different? If it > is, maybe we should try to increase it by simply adding a bit. I think it'd be worth taking a fresh look at the bit allocation in the header word to see if we can squeeze another bit without too much pain. There's basically no remaining headroom in the current design, and it starts to seem like we want some. (I'm also wondering whether the palloc_aligned stuff should have been done some other way than by consuming a context type ID.) regards, tom lane