Francisco Reyes wrote:
> Tom Lane writes:
>
> >What's more, because the line and field buffers are StringInfos that are
> >intended for reuse across multiple lines/fields, they're not simply made
> >equal to the exact size of the big field. They're rounded up to the
> >next power-of-2, ie, if you've read an 84MB field during the current
> >COPY IN then they'll be 128MB apiece. In short, COPY is going to need
> >508MB of process-local RAM to handle this row.
>
> Of shared memory?
No
> I am a little confused,yesterday you said that increasing shared_buffers
> may be counterproductive.
Yes, that's what he said.
> Or you are referring to the OS size?
Yes
> The OS size is 1.6GB, but today I am going to try increasing kern.maxssiz.
> Vivek recommended increasing it
The problem is probably the ulimit. I don't know what kern.maxssiz is
though.
> >In short, you need a bigger per-process memory allowance.
>
> I wrote a mini python program to copy one of the records that is failing.
> The client program is using 475MB with 429MB resident.
>
> The server has been running all night on this single insert.
> The server is using 977MB with 491MB resident.
> Yesterday I saw it grow as big as 1000MB with 900MB+ resident.
Can you send the program along? And the table definition (including
indexes, etc)?
--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"Find a bug in a program, and fix it, and the program will work today.
Show the program how to find and fix a bug, and the program
will work forever" (Oliver Silfridge)
