From: | Alex Hunsaker <badalex(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Christian Schröder <cs(at)deriva(dot)de> |
Subject: | Re: Memory leakage associated with plperl spi_prepare/spi_freeplan |
Date: | 2013-03-01 04:42:04 |
Message-ID: | CAFaPBrRNeP95DX=S-x=QJZMXBgZfYahiCTG56QmZeh4=ErwKVw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 26, 2013 at 3:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> I'm inclined to think the right fix is to make a small memory context
> for each prepared plan made by plperl_spi_prepare(). The qdesc for it
> could be made right in the context (getting rid of the unchecked
> malloc's near the top of the function), the FmgrInfos and their
> subsidiary data could live there too, and plperl_spi_freeplan could
> replace its retail free's with a single MemoryContextDelete.
>
>
Seemed fairly trivial, find the above approach in the attached. I added a
CHECK_FOR_INTERRUPTS() at the top of plperl_spi_prepare(), it was fairly
annoying that I couldn't ctrl+c my way out of test function.
One annonce is it still leaks :-(. I tracked it down and it seemed to stem
from parseTypeString(). I chased down the rabbit hole for a bit, but
nothing jumped out... raw_parser() is a bit of a black box to me. Adding
the seemingly obvious list_free(raw_parsetree_list); or setting the memory
context before parseTypeString() didn't seem to do much.
It would be nice to squish the other leaks due to perm_fmgr_info()... but
this is a start.
Attachment | Content-Type | Size |
---|---|---|
plperl_spi_leak.patch | application/octet-stream | 4.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan Rogers | 2013-03-01 06:40:28 | Re: Btrfs clone WIP patch |
Previous Message | Michael Paquier | 2013-03-01 03:57:35 | Re: Support for REINDEX CONCURRENTLY |