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: | Raw Message | Whole Thread | 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. |