From: | Thomas Hallgren <thomas(at)tada(dot)se> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Question about MemoryContexts and functions that returns |
Date: | 2006-03-21 18:52:47 |
Message-ID: | 44204B7F.1090005@tada.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David,
Thanks for the tip. A diff on the plperl source was really helpful.
As it turns out, I'm not supposed to allocate the returned tuple in the
caller context. Apparently, PostgreSQL will always make a copy of it. I
find this a bit inconsistent with how other return values are handled.
PL/Java initially had some problems when I trusted that values where
copied when in fact they where not. Has the function call semantics
changed in this respect?
Kind Regards,
Thomas Hallgren
David Fetter wrote:
> On Mon, Mar 20, 2006 at 11:47:41AM +0100, Thomas Hallgren wrote:
>
>> Hi,
>> A PL/Java user reports that his backend runs out of memory when he uses
>> PL/Java to execute huge queries towards a remote database and return the
>> result. PL/Java is designed not to collect data in memory when it
>> returns result sets. Each call to the function handler will be
>> dispatched to the corresponding 'ResultSet.next()' in order to retrieve
>> and propagate one row at a time. Yet, it seems the data is collected
>> somewhere. An excerpt from the user at the time he runs out of memory
>> looks like this:
>>
>
> A similar thing happened in PL/Perl up until recently. Check Neil
> Conway's patches to that for hints :)
>
> Cheers,
> D
>
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Maxwell | 2006-03-21 19:00:14 | [GENERAL] A real currency type |
Previous Message | Tom Lane | 2006-03-21 18:52:17 | Re: qsort, once again |