Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Re: Fix memory leak in postmasterMain
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: <3e890874-8204-e1c2-8def-3a02cbad2232@0x48.dk>
Date: Wed, 22 Apr 2026 14:45:29 +0800
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1658D50F-A8B3-406A-94ED-FA8C7F9DA90B@gmail.com>
References: <e84ede22-1b46-0780-64e4-5db4a1e5236f@0x48.dk>
 <3e890874-8204-e1c2-8def-3a02cbad2232@0x48.dk>
To: Henrik TJ <henrik@0x48.dk>
Archived-At: 
 <https://www.postgresql.org/message-id/1658D50F-A8B3-406A-94ED-FA8C7F9DA90B%40gmail.com>
Precedence: bulk


> On Apr 21, 2026, at 22:56, Henrik TJ <henrik@0x48.dk> wrote:
>=20
> Hi
>=20
> On Sat, 21 Feb 2026, Henrik TJ wrote:
>=20
>> This is fairly inconsequential as memory leaks goes, but if -D is =
used when starting postgres, the memory allocated by stdrup() will never =
be freed. Found with valgrind.
>=20
> Rebased version of this patch attached.
>=20
> To see valgrind catch the leak:
>=20
> 1. Compile with valgrind.
> 2. Run postgres with valgrind:
>   valgrind --leak-check=3Dfull ./pgrun/bin/postgres -D pgdata/
>=20
> The -D argument is required, as it is the argument from there that =
does not get freed. This should yield:
>=20
> =3D=3D444240=3D=3D 8 bytes in 1 blocks are definitely lost in loss =
record 29 of 849
> =3D=3D444240=3D=3D    at 0x4840B26: malloc (vg_replace_malloc.c:447)
> =3D=3D444240=3D=3D    by 0x5114A2E: strdup (strdup.c:42)
> =3D=3D444240=3D=3D    by 0x6B7CE0: PostmasterMain =
(../src/backend/postmaster/postmaster.c:656)
> =3D=3D444240=3D=3D    by 0x602555: main =
(../src/backend/main/main.c:231)
>=20
>=20
>  best regards, =
Henrik<v2-0001-Fix-userDoption-not-getting-freed-in-postmaster.patch>

=46rom my experience, most of the time the postmaster is started with =
-D. On Linux and macOS, that path can be quite long, PATH_MAX is often =
4096 on many Unix-like systems, and I am not sure about Windows. So I =
think this leak is worth fixing.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/