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 ;-).
To follow up on this a bit my investigation is not yet complete but
I have constructed some truly-hideous worst-case test code
that I can have execute under valgrind but using the same basic
codebase for everything else (that is, outside of the FastCGI()
wrapper loop) and I've not been able to get libpq to misbehave.
Everything it grabs it gives back as it should.
I've tentatively concluded that the FastCGI wrapper code is doing
this and the fault is likely mine (perhaps due to documentation on
using it that is less-than-complete) although I've not yet
conclusively determined what it is.
Wanted to follow up with what I had found since I did make the
request....
<<attachment: smime.p7s>>
