On 6/27/2022 23:22, Tom Lane wrote:
Karl Denninger<k...@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.... -- Karl Denninger k...@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
