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.96) (envelope-from ) id 1w2B6R-0003lk-2z for pgsql-committers@arkaria.postgresql.org; Mon, 16 Mar 2026 16:47:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w2B6P-00BOrh-39 for pgsql-committers@arkaria.postgresql.org; Mon, 16 Mar 2026 16:47:38 +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.96) (envelope-from ) id 1w2B6P-00BOrX-2R for pgsql-committers@lists.postgresql.org; Mon, 16 Mar 2026 16:47:38 +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.98.2) (envelope-from ) id 1w2B6N-000000002cT-0a9M for pgsql-committers@lists.postgresql.org; Mon, 16 Mar 2026 16:47:37 +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 62GGlSiE035968; Mon, 16 Mar 2026 12:47:28 -0400 From: Tom Lane To: =?utf-8?Q?=C3=81lvaro?= Herrera cc: Mahendra Singh Thalor , pgsql-committers@lists.postgresql.org Subject: Re: pgsql: Fix small memory leak in get_dbname_oid_list_from_mfile(). In-reply-to: <202603161539.zldv3z456gn4@alvherre.pgsql> References: <202603161539.zldv3z456gn4@alvherre.pgsql> Comments: In-reply-to =?utf-8?Q?=C3=81lvaro?= Herrera message dated "Mon, 16 Mar 2026 16:48:04 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35966.1773679648.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Mar 2026 12:47:28 -0400 Message-ID: <35967.1773679648@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk =3D?utf-8?Q?=3DC3=3D81lvaro?=3D Herrera writes: > On 2026-Mar-16, Mahendra Singh Thalor wrote: >> We were trimming slashes due to the below test case. >> = >> *Ex:* >> ./pg_dumpall -f dumpdir --format=3Dd >> = >> ./pg_restore *dumpdir/ *-d postgres -C --format=3Dd --verbose >> pg_restore: found database "template1" (OID: 1) in file "*dumpdir//map.= dat*" >> pg_restore: found database "postgres" (OID: 5) in file "*dumpdir//map.d= at*" >> pg_restore: found 2 database names in "map.dat" >> pg_restore: need to restore 2 databases out of 2 databases >> = >> Here, before map.dat, there were 2 slashes so we were trimming slashes. >> Please add your opinion for this output. > I think this is perfectly fine. Two slashes work correctly, and many > other tools behave this way when given redundant slashes. If the user > doesn't want to see the redundant slashes, they can just not specify a > trailing slash in the argument value. As I said in my commit message, if we wanted to do something about this the correct thing would be to apply canonicalize_path to the constructed strings. On Unix systems that's really just cosmetic, as Alvaro says. But if memory serves it's not necessarily so on Windows. Has anyone tested this patch on Windows, with Windows peculiarities like using backslash separators in the given path? regards, tom lane