Stephan Knauss writes:
> On 31.03.2021 20:24, Tom Lane wrote:
>> Based on nearby threads, it occurs to me to ask whether you have JIT
>> enabled, and if so whether turning it off helps. There seems to be
>> a known leak of the code fragments generated by that in some cases.
> That's it!
> You m
Hello Tom,
On 31.03.2021 20:24, Tom Lane wrote:
Based on nearby threads, it occurs to me to ask whether you have JIT
enabled, and if so whether turning it off helps. There seems to be
a known leak of the code fragments generated by that in some cases.
That's it!
I am quite surprised that a f
On 31.03.2021 20:27, Paul Ramsey wrote:
On Mar 31, 2021, at 11:24 AM, Tom Lane wrote:
If that's not it, then the leak must be accumulating through plain
old malloc calls. There's not much of that in the core backend
(although if you use ispell text search dictionaries, maybe [1] is
relevant),
> On Mar 31, 2021, at 11:24 AM, Tom Lane wrote:
>
> Stephan Knauss writes:
>> Hello Tom, the output below looks similar to the OOM output you
>> expected. Can you give a hint how to interpret the results?
>
> Looks like the answer is that wherever the leak is, it's not accounted
> for by th
Stephan Knauss writes:
> Hello Tom, the output below looks similar to the OOM output you
> expected. Can you give a hint how to interpret the results?
Looks like the answer is that wherever the leak is, it's not accounted
for by this info; none of those contexts are particularly large.
Based on
On 30.03.2021 20:46, Tom Lane wrote:
Stephan Knauss writes:
The wiki suggested to dump MemoryContext states for more details, but
something strange happens when attaching gdb. It seems that the process
is immediately killed and I can no longer dump such details.
(I think the -v option is the o
Stephan Knauss writes:
> The wiki suggested to dump MemoryContext states for more details, but
> something strange happens when attaching gdb. It seems that the process
> is immediately killed and I can no longer dump such details.
You might try running the postmaster under a restrictive ulimit
Hello,
I have a setup in which I have constantly 8 connections to the database
open which query data for map rendering. The query involve only a hand
full of tables, but could be complex and use postgis functions.
The connection stays open. Only read-requests are happening, no
update/insert/
