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 1rb7Q1-00DPAO-7i for pgsql-hackers@arkaria.postgresql.org; Fri, 16 Feb 2024 23:14:57 +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 1rb7Pz-005HzE-G9 for pgsql-hackers@arkaria.postgresql.org; Fri, 16 Feb 2024 23:14:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rb7Pz-005Hz5-6v for pgsql-hackers@lists.postgresql.org; Fri, 16 Feb 2024 23:14:55 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rb7Ps-007a0z-Sl for pgsql-hackers@lists.postgresql.org; Fri, 16 Feb 2024 23:14:54 +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 41GNEibT3537324; Fri, 16 Feb 2024 18:14:44 -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: Comments: In-reply-to Tomas Vondra message dated "Fri, 16 Feb 2024 23:46:03 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3537322.1708125284.1@sss.pgh.pa.us> Date: Fri, 16 Feb 2024 18:14:44 -0500 Message-ID: <3537323.1708125284@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Tomas Vondra writes: > Maybe I'm completely misunderstanding the implication of those limits, > but doesn't this mean the claim that we can support 8 memory context > types is not quite true, and the limit is 4, because the 4 IDs are > already used for malloc stuff? Well, correct code would still work, but we will take a hit in our ability to detect bogus chunk pointers if we convert any of the four remaining bit-patterns to valid IDs. That has costs for debugging. The particular bit patterns we left unused were calculated to make it likely that we could detect a malloced-instead-of-palloced chunk (at least with glibc); but in general, reducing the number of invalid patterns makes it more likely that a just-plain-bad pointer would escape detection. I am less concerned about that than I was in 2022, because people have already had some time to flush out bugs associated with the GUC malloc->palloc conversion. Still, maybe we should think harder about whether we can free up another ID bit before we go eating more ID types. It's not apparent to me that the "bump context" idea is valuable enough to foreclose ever adding more context types, yet it will be pretty close to doing that if we commit it as-is. If we do kick this can down the road, then I concur with eating 010 next, as it seems the least likely to occur in glibc-malloced chunks. > One thing that confuses me a bit is that the comments introduced by > 80ef92675823 talk about glibc, but the related discussion in [1] talks a > lot about FreeBSD, NetBSD, ... which don't actually use glibc (AFAIK). 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? regards, tom lane