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 1nK9Ol-0005Ig-Gu for pgsql-bugs@arkaria.postgresql.org; Wed, 16 Feb 2022 01:46:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nK9OE-0005Wu-K7 for pgsql-bugs@arkaria.postgresql.org; Wed, 16 Feb 2022 01:45:54 +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 1nK9OE-0005Wl-CB for pgsql-bugs@lists.postgresql.org; Wed, 16 Feb 2022 01:45:54 +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 1nK9O9-0001ZD-Vb for pgsql-bugs@lists.postgresql.org; Wed, 16 Feb 2022 01:45:53 +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 21G1jk2Y3239747; Tue, 15 Feb 2022 20:45:46 -0500 From: Tom Lane To: Andres Freund cc: Daniel Gustafsson , wliang@stu.xidian.edu.cn, pgsql-bugs Subject: Re: Report a potential memory leak in setup_config() In-reply-to: <20220216012953.6d7bzmsblqou3ru4@alap3.anarazel.de> References: <64ee7543.20d.17efb1270ca.Coremail.wliang@stu.xidian.edu.cn> <3052163.1644942806@sss.pgh.pa.us> <20220216012953.6d7bzmsblqou3ru4@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Tue, 15 Feb 2022 17:29:53 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3239745.1644975946.1@sss.pgh.pa.us> Date: Tue, 15 Feb 2022 20:45:46 -0500 Message-ID: <3239746.1644975946@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > On 2022-02-15 11:33:26 -0500, Tom Lane wrote: >> It might be worth trying to knock that down a bit, but I wouldn't >> start with a one-time leak of 28 bytes. It looks like the biggest >> offender is that we don't bother trying to reclaim the lines >> malloc'd by readfile() and replace_token(). Fixing that is *maybe* >> worth the trouble, but TBH no one has complained about initdb's >> memory consumption. > It's a bit insane that we allocate the lines[] quite so many times, when > processing the same file. Yeah, I noticed that --- why don't we reuse the array of pointers? Not sure it'd save much compared to freeing the strings, but it is mighty low-hanging fruit. > The replacement patterns either are > compile time constants which we just should handle in genbki.pl, or have > exactly 1 replacement.... Mmm, really? I thought most of them were data that we don't know until initdb runs. Anything that really is known at build time, sure, genbki.pl ought to take care of. regards, tom lane