From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Francisco Reyes <lists(at)stringsutils(dot)com> |
Cc: | PostgreSQL general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_restore out of memory |
Date: | 2007-06-15 21:21:12 |
Message-ID: | 22509.1181942472@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Francisco Reyes <lists(at)stringsutils(dot)com> writes:
> Tom Lane writes:
>> Well, that's the last few lines of what I wanted, but not the part that
>> was interesting :-(. Please show all the lines that are like the "n
>> total in m blocks" format. Or at least look for the one(s) that contain
>> large numbers...
> Since you know best what you are looking for I just put the log for you at
> http://public.natserv.net/postgresql-2007-06-15.log
The only important space consumption seems to be here:
PortalHeapMemory: 335682660 total in 13 blocks; 68880 free (52 chunks); 335613780 used
So it's not a deferred-trigger problem (trigger events would be in their
own context). Also, the fact that it's trying to allocate exactly 128MB
lets out a lot of possibilities --- that has to be a single huge
request, not just the end result of a boatload of little ones. So it
probably isn't a memory leak per se.
One time that we've seen something like this before is when someone
had a COPY datafile that had had its newlines munged, such that COPY
thought it was all one long line and tried to read it all in at once.
What's the history of your datafile --- has it maybe gotten passed
through a Windows newline conversion?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gary Fu | 2007-06-15 22:08:09 | Re: allocate chunk of sequence |
Previous Message | Scott Marlowe | 2007-06-15 20:46:18 | Re: allocate chunk of sequence |