Karl Denninger <karl@xxxxxxxxxxxxx> writes: > But -- I still have a /lot /of memory out on the heap according to > jemalloc stats that is not being deallocated, and what's worse is that > if I rig the code to call PQfinish and then PQconnect once again I get > /even more /imbalanced allocate/free counts (and the memory use in said > buckets to go with them.) Hmmm ... I'm not aware of any memory leaks in libpq, but that doesn't mean there are none. Of course, if you're forgetting to PQclear() some PGresults, that's not libpq's fault ;-). > The obvious question, given the warnings in the FastCGI library: Does > libpq /modify /the process environment? No. At least, I see no setenv() calls in it, and I think that it'd be pretty unfriendly for a library to do that to its host application. > A quick grep implies that indeed it may in > backend/libpq/auth.c at least, backend/libpq is unrelated to interfaces/libpq. (I've seen hints that they arose from a common code base, but if so, that was a few decades and a lot of rewrites ago.) regards, tom lane
