From: | Karl Denninger <karl(at)denninger(dot)net> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Libpq question related to allocated resources |
Date: | 2022-07-02 18:30:52 |
Message-ID: | 950bc06e-c5aa-f11e-1195-901e6bd17bad@denninger.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 6/27/2022 23:22, Tom Lane wrote:
> Karl Denninger<karl(at)denninger(dot)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
karl(at)denninger(dot)net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
From | Date | Subject | |
---|---|---|---|
Next Message | shashidhar Reddy | 2022-07-03 09:39:07 | plpgsql_check issue while upgrading from postgres version 12 to 13.7 |
Previous Message | vignesh C | 2022-07-02 14:24:51 | Re: Support logical replication of DDLs |