| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Orlov Aleksej <al(dot)orlov(at)cft(dot)ru> |
| Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Fix memory leak in memoize for numeric key |
| Date: | 2023-10-03 08:51:31 |
| Message-ID: | CAApHDvqX=3N0TguBwV-3nRAA5nR_jcvdMwPaTFoMBwjbTsxgOw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 3 Oct 2023 at 19:38, Orlov Aleksej <al(dot)orlov(at)cft(dot)ru> wrote:
> I found a query which consumes a lot of memory and triggers OOM killer.
> Memory leak occurs in memoize node for numeric key.
Thanks for the analysis and the patch.
> I've attached memoize_memory_leak_numeric_key.patch to address this.
Yeah, this is a bug for sure.
Looking at ExecHashGetHashValue() for example purposes, I see it's
quite careful to call ResetExprContext(econtext) at the top of the
function to reset the tuple context.
I think the patch might need to go a bit further and also adjust
MemoizeHash_equal(). In non-binary mode, we just call
ExecQualAndReset() which evaluates the join condition and resets the
context. The binary mode code does not do this, so I think we should
expand on what you've done and adjust that code too.
I've done that in the attached patch.
David
| Attachment | Content-Type | Size |
|---|---|---|
| fix_memoize_memory_leak_v2.patch | application/octet-stream | 1.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2023-10-03 09:21:13 | Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag |
| Previous Message | Michael Paquier | 2023-10-03 07:30:09 | Re: [PGDOCS] Inconsistent linkends to "monitoring" views. |