From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | wliang(at)stu(dot)xidian(dot)edu(dot)cn, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Report a potential memory leak in setup_config() |
Date: | 2022-02-15 16:33:26 |
Message-ID: | 3052163.1644942806@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 15 Feb 2022, at 02:49, wliang(at)stu(dot)xidian(dot)edu(dot)cn wrote:
>> Specifically, at line 1095, function pretty_wal_size() is called, which allocates a chunk of memory by using pg_malloc and returns it. However, the return chunk is directly passed to snprintf as its 3rd parameter. As a result, there is a memory leak.
> PostgreSQL isn't all too concerned about small static leaks in short lived
> programs, like initdb. Memory will be freed shortly when the program exits.
> Complicating the code to save 28 bytes seems hardly worth it, but if you feel
> strongly about it I suggest proposing a patch to fix it.
Yeah. A quick run of initdb under valgrind reports
==3051337== LEAK SUMMARY:
==3051337== definitely lost: 893,446 bytes in 47 blocks
==3051337== indirectly lost: 4,490 bytes in 51 blocks
==3051337== possibly lost: 0 bytes in 0 blocks
==3051337== still reachable: 2,403 bytes in 22 blocks
==3051337== suppressed: 0 bytes in 0 blocks
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-02-15 16:36:48 | Re: Report a potential memory leak in describeOneTableDetails() |
Previous Message | Tom Lane | 2022-02-15 16:12:32 | Re: BUG #17404: CREATE OR REPLACE VIEW does not properly change the COLLATION of an existing field. |