Re: [PATCH] ecpg: fix progname memory leak

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Meskes <meskes(at)postgresql(dot)org>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: [PATCH] ecpg: fix progname memory leak
Date: 2020-10-08 17:17:25
Message-ID: 2575996.1602177445@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Meskes <meskes(at)postgresql(dot)org> writes:
> On Thu, 2020-10-08 at 12:27 -0400, Bruce Momjian wrote:
>> Agreed, but what does the TODO item mean then?
>>
>> Fix small memory leaks in ecpg
>> Memory leaks in a short running application like ecpg are not really
>> a problem, but make debugging more complicated
>>
>> Should it be removed?

> I'd say yes, let's remove it. Actually I wasn't even aware it's on
> there. While I agree that it makes debugging of memory handling in ecpg
> more difficult, I don't see much of a point in it.

Agreed. In theory there might be some point in removing leaks that happen
per-statement, so as to avoid unreasonable memory bloat when processing an
extremely long input file. In practice nobody has complained about that,
and if somebody did I'd probably question the sanity of putting so much
code into one file. (The C compiler would likely bloat even more while
processing the output...) Moreover, given the way the ecpg grammar works,
it'd be really painful to avoid all such leaks, and it might well
introduce bugs not fix them.

In any case, if this TODO item is going to lead to ideas as dubious
as "let's free progname before exiting", it's not helpful.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Westermann (DWE) 2020-10-08 18:12:47 Re: Wrong example in the bloom documentation
Previous Message Bruce Momjian 2020-10-08 17:17:10 Re: [PATCH] ecpg: fix progname memory leak