From: | Thomas Hallgren <thomas(at)tada(dot)se> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Fetter <david(at)fetter(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Question about MemoryContexts and functions that returns |
Date: | 2006-03-21 23:45:13 |
Message-ID: | 44209009.3060506@tada.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Thomas Hallgren <thomas(at)tada(dot)se> writes:
>
>> As it turns out, I'm not supposed to allocate the returned tuple in the
>> caller context.
>>
>
> Where do you get that from? plpgsql and plperl both do it that way AFAICS.
>
> Are you testing in an --enable-cassert build? The memory-clobber
> behavior that that turns on is really essential for finding
> dangling-pointer problems ...
>
>
I use --enable-cassert. I don't think my problem is a dangling pointer.
I just created a dummy C-function that short circuits the
java_call_handler. It calls my real java function with the correct
parameters. When I register this function with language C and use it
instead of the normal function that calls via the java call handler,
there's no memory leak. It only leaks memory when I go through the call
handler. The call handler doesn't execute many lines of code and from
what I can tell, it doesn't manipulate contexts at all. Nor does it
allocate anything. Further more, I can prevent the leak by allocating
the returned tuple in a context of my own and free it on the next call.
Is there a difference in how the executor treat a C function and a
function using a call handler that can cause this behavior?
Regards,
Thomas Hallgren
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-03-21 23:46:04 | Re: 8.2 planning features |
Previous Message | Tom Lane | 2006-03-21 23:33:15 | Re: Poor performance o |