Re: Memory leak on subquery as scalar operand - Mailing list pgsql-bugs

From Daniel Gustafsson
Subject Re: Memory leak on subquery as scalar operand
Date
Msg-id 452E97A1-93EE-473C-A9D3-E878EF3543CF@yesql.se
Whole thread Raw
In response to Re: Memory leak on subquery as scalar operand  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Memory leak on subquery as scalar operand
List pgsql-bugs
Attached is a v6 rebase of this patchset which curbs a memory leak in llvmjit
by explicitly using an LLVMContextRef for types which is dropped and recreated
at intervals to free unused types.  The attached graph plots the memory usage
of a backend continuously running the query from the OP in this thread.  The
patched version (running with all JIT costs at zero to get all inlining etc)
goes to a levelled off memory usage where master just continues to grow until
terminated.  There is more to do on llvmjit memory usage, but this is clearly a
win for queries which otherwise accumulte type leaks potentially ending with an
OOM.

0001 and 0002 are tangentially related, but are mainly of cleanup character.
0003 contains the LLVMContextRef work which is the meat of the patchset.

I think it would be good to get this in early in the v17 cycle such that we
have time to revisit the herustic if need be.

Thoughts?

--
Daniel Gustafsson






Attachment

pgsql-bugs by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [16] ALTER SUBSCRIPTION ... SET (run_as_owner = ...) is a no-op
Next
From: Tom Lane
Date:
Subject: Re: the same time value return different values,is it a problem