Re: Fix memory leak in postmasterMain

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Henrik TJ <henrik(at)0x48(dot)dk>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix memory leak in postmasterMain
Date: 2026-04-22 06:45:29
Message-ID: 1658D50F-A8B3-406A-94ED-FA8C7F9DA90B@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Apr 21, 2026, at 22:56, Henrik TJ <henrik(at)0x48(dot)dk> wrote:
>
> Hi
>
> On Sat, 21 Feb 2026, Henrik TJ wrote:
>
>> 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.
>
> Rebased version of this patch attached.
>
> To see valgrind catch the leak:
>
> 1. Compile with valgrind.
> 2. Run postgres with valgrind:
> valgrind --leak-check=full ./pgrun/bin/postgres -D pgdata/
>
> The -D argument is required, as it is the argument from there that does not get freed. This should yield:
>
> ==444240== 8 bytes in 1 blocks are definitely lost in loss record 29 of 849
> ==444240== at 0x4840B26: malloc (vg_replace_malloc.c:447)
> ==444240== by 0x5114A2E: strdup (strdup.c:42)
> ==444240== by 0x6B7CE0: PostmasterMain (../src/backend/postmaster/postmaster.c:656)
> ==444240== by 0x602555: main (../src/backend/main/main.c:231)
>
>
> best regards, Henrik<v2-0001-Fix-userDoption-not-getting-freed-in-postmaster.patch>

From 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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kirill Reshke 2026-04-22 06:49:32 Cleanup explain_memoize function after test
Previous Message David Geier 2026-04-22 06:45:01 Re: Wrong results with equality search using trigram index and non-deterministic collation