On 6/27/2022 23:22, Tom Lane wrote:
Karl Denninger <karl@denninger.net> 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....
