Neil Conway <neilc@samurai.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
bugs. However:
>> [BUG] memory leak on error path (dtype != DTK_DELTA)
>> File where bug occurred:
>> postgresql-7.4.2/src/interfaces/ecpg/pgtypeslib/interval.c
> 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
