Re: Fix some memory leaks in ecpg.addons - Mailing list pgsql-hackers

From Michael Meskes
Subject Re: Fix some memory leaks in ecpg.addons
Date
Msg-id dfd2baf0a2021dc3b66013c7cdf5bd5e152b4fbd.camel@postgresql.org
Whole thread Raw
In response to Re: Fix some memory leaks in ecpg.addons  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fix some memory leaks in ecpg.addons
List pgsql-hackers
Am Mittwoch, dem 08.11.2023 um 12:07 -0500 schrieb Tom Lane:
> "Tristan Partin" <tristan@neon.tech> writes:
> > clang and gcc both now support -fsanitize=address,undefined. These
> > are
> > really useful to me personally when trying to debug issues.
> > Unfortunately ecpg code has a ton of memory leaks, which makes
> > builds
> > really painful. It would be great to fix all of them, but I don't
> > have
> > the patience to try to read flex/bison code. Here are two memory
> > leak
> > fixes in any case.
>
> I'm kind of failing to see the point.  As you say, the ecpg
> preprocessor leaks memory like there's no tomorrow.  But given its
> usage (process one source file and exit) I'm not sure that is worth
> much effort to fix.  And what does it buy to fix just two spots?

Agreed, it's not exactly uncommon for tools like ecpg to not worry
about memory. After all it gets freed when the program ends.

Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Syncrep and improving latency due to WAL throttling
Next
From: Andres Freund
Date:
Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends.