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 1q1WpL-0001Jt-2y for pgsql-hackers@arkaria.postgresql.org; Tue, 23 May 2023 18:33:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q1WpJ-0001rD-3U for pgsql-hackers@arkaria.postgresql.org; Tue, 23 May 2023 18:33:41 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q1WpI-0001r4-QT for pgsql-hackers@lists.postgresql.org; Tue, 23 May 2023 18:33:40 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q1WpB-001hn9-8g for pgsql-hackers@lists.postgresql.org; Tue, 23 May 2023 18:33:40 +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 34NIXRE2973023; Tue, 23 May 2023 14:33:28 -0400 From: Tom Lane To: Andres Freund cc: Tomas Vondra , PostgreSQL Hackers Subject: Re: memory leak in trigger handling (since PG12) In-reply-to: <20230523180113.3qqpbnvndbyyqrcr@awork3.anarazel.de> References: <222a3442-7f7d-246c-ed9b-a76209d19239@enterprisedb.com> <20230523171433.earidmyzock7fnk4@awork3.anarazel.de> <965727.1684862910@sss.pgh.pa.us> <20230523180113.3qqpbnvndbyyqrcr@awork3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Tue, 23 May 2023 11:01:13 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <973021.1684866807.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 23 May 2023 14:33:27 -0400 Message-ID: <973022.1684866807@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > On 2023-05-23 13:28:30 -0400, Tom Lane wrote: >> Why? Unlike Lists, those things are already a single palloc chunk. > We do a fair amount of 8 byte allocations - they have quite a bit of ove= rhead, > even after c6e0fe1f2a0. Not needing allocations for the common case of > bitmapsets with a max member < 63 seems like it could be worth it. Oh, now I understand what you meant: use the pointer's bits as data. Dunno that it's a good idea though. You'd pay for the palloc savings by needing two or four code paths in every bitmapset function, because the need to reserve one bit would mean you couldn't readily make the two cases look alike at the bit-pushing level. Another big problem is that we'd have to return to treating bitmapsets as a special-purpose thing rather than a kind of Node. While that's not very deeply embedded yet, I recall that the alternatives weren't attractive. Also, returning to the original topic: we'd never find leaks of the sort complained of here, because they wouldn't exist in cases with fewer than 64 relations per query (or whatever the bitmap is representing). regards, tom lane