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 1nK0p0-0001gU-Me for pgsql-bugs@arkaria.postgresql.org; Tue, 15 Feb 2022 16:36:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nK0oz-0004Lw-Ed for pgsql-bugs@arkaria.postgresql.org; Tue, 15 Feb 2022 16:36:57 +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 1nK0oz-0004Ln-6g for pgsql-bugs@lists.postgresql.org; Tue, 15 Feb 2022 16:36:57 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nK0os-0006cH-9d for pgsql-bugs@lists.postgresql.org; Tue, 15 Feb 2022 16:36:56 +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 21FGaml53052378; Tue, 15 Feb 2022 11:36:48 -0500 From: Tom Lane To: wliang@stu.xidian.edu.cn cc: pgsql-bugs Subject: Re: Report a potential memory leak in describeOneTableDetails() In-reply-to: <110a333f.359.17efb204b17.Coremail.wliang@stu.xidian.edu.cn> References: <110a333f.359.17efb204b17.Coremail.wliang@stu.xidian.edu.cn> Comments: In-reply-to wliang@stu.xidian.edu.cn message dated "Tue, 15 Feb 2022 10:05:04 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3052376.1644943008.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Feb 2022 11:36:48 -0500 Message-ID: <3052377.1644943008@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk wliang@stu.xidian.edu.cn writes: > I find a potential memory leak in PostgresSQL 14.1, which is in the func= tion describeOneTableDetails (./src/bin/psql/describe.c). Do you want to submit a patch? The amount of memory involved here isn't much, but since psql is a potentially long-running program, it seems worth the trouble to be careful. I think the best fix might be to drop these strdup's altogether, and instead postpone freeing the PGresult to the end of the function, so that we can just use the pointers returned by PQgetvalue. regards, tom lane