Neil Conway <neilc(at)samurai(dot)com> writes:
> The problem with applying this kind of static analysis to PostgreSQL is
> that palloc() is not like malloc(): if the return value goes out of
> scope before it is freed, it is NOT necessarily the case that a memory
> leak has occurred.
I'm a bit surprised that a tool unaware of this fact would generate only
four complaints ... I'd have expected hundreds.
I concur with Neil's opinion that none of the backend cases represent
>> [BUG] memory leak on error path (dtype != DTK_DELTA)
>> File where bug occurred:
> Looks suspicious to me, but ECPG is Michael Meskes' domain -- Michael?
It's entirely likely that ecpg's derivative of the backend's datetime
modules contains lots and lots of memory leaks, since AFAIK the palloc
infrastructure is not there in the ecpg environment :-(.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2004-05-02 23:51:15|
|Subject: Re: Fixed directory locations in installs|
|Previous:||From: Alvaro Herrera||Date: 2004-05-02 23:15:43|
|Subject: Re: SET WITHOUT CLUSTER patch|
pgsql-bugs by date
|Next:||From: Ted Kremenek||Date: 2004-05-03 03:22:07|
|Subject: Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2 |
|Previous:||From: Ted Kremenek||Date: 2004-05-02 20:45:35|
|Subject: Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2|