Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199403240230.SAA18964@nobozo.CS.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
Message-Id: <199403240230.SAA01975@faerie.CS.Berkeley.EDU>
From: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
To: suresh@nlm.nih.gov (Suresh Srinivasan)
Cc: postgres@postgres.Berkeley.EDU, rodgers@nls2.nlm.nih.gov
Subject: Re: Core dump when copy'ing large file 
Reply-To: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
In-reply-to: Your message of Mon, 7 Mar 94 10:26:22 EST 
	     <9403071526.AA11157@nls2.csb> 
Date: Wed, 23 Mar 94 18:30:11 -0800
Resent-To: postgres-dist@postgres.Berkeley.EDU
Resent-Date: Wed, 23 Mar 94 18:30:37 -0800
Resent-XMts: smtp

suresh@nlm.nih.gov (Suresh Srinivasan) writes:
> Well, after running for about 5 hrs on a Sparc 2, I get a
> core dump (?() at ab058 using adb) with the following message
> on the console:

i'm not positive this is your problem, but..

postgres has problems with memory leaks when you start working with 
many rows.  the fundamental problem is that there are data structures 
that get created per-row that don't get freed until end-of-transaction.
for example, people have noted that single-transaction inserts of 
several thousand rows fail.  sunita sarawagi tried to track down as 
many of these leaks as she could, but they are pervasive.

the codepaths less travelled (insert, copy, etc.) seem to have more 
problems with this than some others (retrieve).

if this is the problem (malloc is returning NULL because you're out of 
memory) the only fixes i can suggest are to break up the load into 
several chunks or allocate a lot more swap space.

if you are trying to copy *out* and having this problem, one should
be able to break a table up using "retrieve into" (creating a set of 
temporary tables) and then "copy out" from the temporary tables.
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki