| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>, lauri(dot)laanmets(at)eesti(dot)ee, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Memory leak on subquery as scalar operand |
| Date: | 2023-09-13 13:24:42 |
| Message-ID: | 452E97A1-93EE-473C-A9D3-E878EF3543CF@yesql.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 | Content-Type | Size |
|---|---|---|
| v6-0003-llvmjit-Use-explicit-LLVMContextRef-for-inlining.patch | application/octet-stream | 32.4 KB |
| v6-0002-llvmjit-Make-llvm_types_module-variable-static.patch | application/octet-stream | 1.6 KB |
| v6-0001-llvmjit-Remove-unnecessary-types.patch | application/octet-stream | 1.6 KB |
| unknown_filename | text/plain | 4 bytes |
| PastedGraphic-1.pdf | application/pdf | 12.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-09-13 14:17:28 | Re: the same time value return different values，is it a problem |
| Previous Message | Amit Kapila | 2023-09-13 10:42:45 | Re: [16] ALTER SUBSCRIPTION ... SET (run_as_owner = ...) is a no-op |