Thread: Memory exhausted in AllocSetAlloc(269039)

Memory exhausted in AllocSetAlloc(269039)

From
"Jeff Barrett"
Date:
I have a function that takes a comma seperated string from another table and
parses it into another table. When I run it on a string with 130 ids it
works fine, when I run it on a string with 50,000 ids (each about 6
characters long) I get the Error: Memory exhausted in AllocSetAlloc(269039).

The system is a dual cpu intel with 1gig of ram and 1gig of swap space.
Before I run the function I start top and it shows about 800mb of ram in
use. This quickly excellerates until all ram is full and then fills up the
swap space then postgres pukes the error message. It is running postgres
7.1.

The questions I have are: Is my script that inefficent that I am using up all of my ram? (I know the
string of ids in another table is horribly inefficent, but it is a
historical nessesity I would rather avoid changing.) What is taking up all of this ram, how can I even trace the
problemdown?
 

CREATE FUNCTION membidsintotable(INTEGER) RETURNS boolean AS '
DECLARE string_rec RECORD; resdataid ALIAS FOR $1;
BEGIN
 SELECT INTO string_rec membids FROM listresultmembids WHERE listresdataid
= resdataid;
 IF NOT FOUND THEN   RETURN FALSE; END IF;
 WHILE char_length(string_rec.membids) > 0 LOOP
   INSERT INTO listmembids VALUES (resdataid, substring(string_rec.membids
FROM 0 FOR position('','' in string_rec.membids)));
   string_rec.membids := trim(leading substring(string_rec.membids FROM 0
FOR position('','' in string_rec.membids)) FROM string_rec.membids);   string_rec.membids := trim(leading '','' FROM
string_rec.membids);END LOOP;
 
 RETURN TRUE;
END;
' LANGUAGE 'plpgsql';


Thanks for the help,

Jeff Barrett




Re: Memory exhausted in AllocSetAlloc(269039)

From
Tom Lane
Date:
"Jeff Barrett" <jbarrett@familynetwork.com> writes:
> I have a function that takes a comma seperated string from another table and
> parses it into another table. When I run it on a string with 130 ids it
> works fine, when I run it on a string with 50,000 ids (each about 6
> characters long) I get the Error: Memory exhausted in AllocSetAlloc(269039).

Seems to run fine in 7.2beta.  Prior versions of plpgsql tended to leak
memory within a function call, but that's been worked on in 7.2.

If you don't care to run beta code, you could possibly work around the
problem in 7.1 by subdividing your function.  Look in the archives for
a prior discussion of this issue (last summer, I think).
        regards, tom lane


Any patch for delete and insert same row in a function ( transaction )

From
MindTerm
Date:
Hi all,
Postgresql shows error message 
"triggered data change violation on relation"when trying to insert and delete same row ( same
primary key ) with in a function or transaction.
Does any solution available to solve this problem ?
Thx. 

M.T.

__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com


Re: Memory exhausted in AllocSetAlloc(269039)

From
Roberto Mello
Date:
On Tue, Dec 04, 2001 at 05:43:17PM -0500, Tom Lane wrote:
> 
> Seems to run fine in 7.2beta.  Prior versions of plpgsql tended to leak
> memory within a function call, but that's been worked on in 7.2.

Tom,

Would you please ellaborate on this leak? We are using PL/pgSQL heavily
on OpenACS and these details would help to make a decision to support 7.1
or push for 7.2.

Thanks,

-Roberto

-- 
+----| http://fslc.usu.edu USU Free Software & GNU/Linux Club |------+ Roberto Mello - Computer Science, USU -
http://www.brasileiro.net      http://www.sdl.usu.edu - Space Dynamics Lab, Developer    
 
ASCII stupid question, get stupid ANSI.


Re: Memory exhausted in AllocSetAlloc(269039)

From
Tom Lane
Date:
Roberto Mello <rmello@cc.usu.edu> writes:
> On Tue, Dec 04, 2001 at 05:43:17PM -0500, Tom Lane wrote:
>> Seems to run fine in 7.2beta.  Prior versions of plpgsql tended to leak
>> memory within a function call, but that's been worked on in 7.2.

> Would you please ellaborate on this leak? We are using PL/pgSQL heavily
> on OpenACS and these details would help to make a decision to support 7.1
> or push for 7.2.

I don't recall all the details, but some plpgsql constructs would use
memory that wouldn't be reclaimed until function exit.  So if you
had a long-running loop inside a function, you could see memory
problems.

I'm not convinced that 7.2 is *entirely* free of such problems, but it's
a lot better than 7.1 was.
        regards, tom lane


Re: Any patch for delete and insert same row in a function (

From
Stephan Szabo
Date:
On Wed, 5 Dec 2001, MindTerm wrote:

> Hi all,
>
>  Postgresql shows error message
> "triggered data change violation on relation"
>  when trying to insert and delete same row ( same
> primary key ) with in a function or transaction.
>
>  Does any solution available to solve this problem ?

This check has been taken out for 7.2.  In the meantime
you can probably just comment out the lines that do the
error in backend/commands/trigger.c



Re: Any patch for delete and insert same row in a function ( transaction

From
Bruce Momjian
Date:
> Hi all,
> 
>  Postgresql shows error message 
> "triggered data change violation on relation"
>  when trying to insert and delete same row ( same
> primary key ) with in a function or transaction.
> 
>  Does any solution available to solve this problem ?

Sorry, I should have said this will be fixed in 7.2.  You can try 7.2beta3
if you wish to test it.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Any patch for delete and insert same row in a function ( transaction

From
Bruce Momjian
Date:
> Hi all,
> 
>  Postgresql shows error message 
> "triggered data change violation on relation"
>  when trying to insert and delete same row ( same
> primary key ) with in a function or transaction.
> 
>  Does any solution available to solve this problem ?

This is fixed in 7.2.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026