Re: BUG #2225: Backend crash -- BIG table

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Patrick Rotsaert <patrick(dot)rotsaert(at)arrowup(dot)be>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #2225: Backend crash -- BIG table
Date: 2006-02-03 13:28:23
Message-ID: 20060203132823.GA25052@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Feb 01, 2006 at 17:57:50 +0100,
Patrick Rotsaert <patrick(dot)rotsaert(at)arrowup(dot)be> wrote:
> I did read it, very carefully. The proposed fix will only work in 2.6
> kernels. Mine is a 2.4 and upgrading it is not an option. The document
> suggests to look at the kernel source for 2.4 kernels. I did that, as I
> wrote in the previous mail. Setting the overcommit parameter to '2', or
> any value for that matter, won't do any good because in this kernel, it
> is only tested if it is non-zero. On my system, the parameter is 0, so
> overcommit is *not* enabled. I don't know what else I can do.
> The other proposed option is to install more memory. Sorry, not an
> option, 1GB has to be sufficient.

Is there some reason you can't add more swap space?

> Apart from the overcommit subject, why is postgres consuming so much
> memory? Should the solution of this problem not be searched for here?

How do you know it is Postgres that is using lots of memory? The OOM killer
doesn't just kill of memory hogs, so you can't just assume the processes
being killed tells you which processes were using lots of memory.

The memory that Postgres uses is controlled in postgresql.conf. One particular
gotcha is that sortmem is per sort, so if you have a number of concurrent
sorts you might be using more memory than you expected.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2006-02-03 14:51:20 Re: BUG #2234: terminated by signal 11
Previous Message Per Lauvaas 2006-02-03 12:38:24 BUG #2235: Wal archiving problems