I'm from the Stanford Metacompilation research group where we use static analysis to find bugs.
Neat. BTW, I saw a talk last summer from Madanlal Musuvathi on some model checking work which I believe is being done by a related group at Stanford; it was very interesting.
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. Each palloc() allocation occurs within a "memory context" (a.k.a an arena, if you're familiar with the usage in tcc). Individual allocations can be released via pfree(), or the entire memory context and all memory allocated within it can be released via MemoryContextReset() or a similar function. Some areas of the code bother doing a pfree() for each palloc(); some do not.
[BUG] memory leak of vacrelstats at end of function laxy_vaccum_rel()
File where bug occurred: postgresql-7.4.2/src/backend/commands/vacuumlazy.c
I believe the CommitTransactionCommand() at vacuum.c:894 (which calls CommitTransaction(), which calls AtCommit_Memory(), which performs a MemoryContextDelete()) deallocates this memory reasonably soon after it has been allocated, so this isn't a bug.
[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?
[BUG] difficult to analyze, but it appears that subquery is memory leaked
File where bug occurred: postgresql-7.4.2/src/backend/optimizer/plan/subselect.c
Not sure about this one -- I didn't bother tracking down exactly where the memory context manipulation happens, but I think it's likely that we release this memory fairly soon after it's allocated.
[BUG] memory leak, pformats is allocated but never freed or stored anywhere
Doesn't look like a bug to me: pformats is allocated in the MessageContext (e.g. tcop/postgres.c:1308), which is reset for every FE command that is processed (e.g. postgres.c:2849).
-Neil
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
