Since the tool is in its nascent stages, I reported only a handful of
reports that I myself looked at felt that they were potentially bugs.
I appreciate everyone's feedback.
On May 2, 2004, at 4:50 PM, Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
>> The problem with applying this kind of static analysis to PostgreSQL
>> 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
> four complaints ... I'd have expected hundreds.
> I concur with Neil's opinion that none of the backend cases represent
> bugs. However:
>>> [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
> ---------------------------(end of
> TIP 5: Have you checked our extensive FAQ?
In response to
pgsql-hackers by date
|Next:||From: Philip Warner||Date: 2004-05-03 03:35:18|
|Subject: Re: ANALYZE locks pg_listener in EXCLUSIVE for long|
|Previous:||From: Bruce Momjian||Date: 2004-05-03 03:13:04|
|Subject: Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?|
pgsql-bugs by date
|Next:||From: Timo Nentwig||Date: 2004-05-03 16:08:23|
|Subject: Bug in optimizer|
|Previous:||From: Tom Lane||Date: 2004-05-02 23:50:46|
|Subject: Re: [CHECKER] 4 memory leaks in Postgresql 7.4.2 |