Re: Crash in PostgreSQL-8.2.4 while executing query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "rupesh bajaj" <rupesh(dot)bajaj(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org, haritsa(at)dsl(dot)serc(dot)iisc(dot)ernet(dot)in, rupesh(at)dsl(dot)serc(dot)iisc(dot)ernet(dot)in, "sharath kumar" <k(dot)sharat(at)gmail(dot)com>
Subject: Re: Crash in PostgreSQL-8.2.4 while executing query
Date: 2007-07-07 21:12:38
Message-ID: 11983.1183842758@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"rupesh bajaj" <rupesh(dot)bajaj(at)gmail(dot)com> writes:
> When I run the following query Postmaster crashes.
> ...
> LOG: background writer process (PID 5808) was terminated by signal 9
> LOG: terminating any other active server processes
> LOG: statistics collector process (PID 5809) was terminated by signal 9

Signal 9 is not Postgres' fault. That means the kernel OOM killer has
decided to kill these processes as a result of a system-wide
out-of-memory condition. (Given that the bgwriter never gets very
large, these seem to be particularly misdirected OOM kills, but the
entire "feature" is pretty broken anyway.)

The planner seems to think that the query will return 4.8 billion rows;
does that have anything to do with reality? If so, what's probably
happening is that the client side is running out of memory to buffer the
result, and the kernel is killing some other process instead of the one
that actually ate all the memory. (Not an unusual behavior at all for
the OOM killer.)

Suggestions:
1. Turn off memory overcommit in your kernel settings.
2. Reconsider whether this query is what you actually wanted.
3. If it is, use a cursor to fetch the result in segments.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2007-07-07 21:25:09 Re: Crash in PostgreSQL-8.2.4 while executing query
Previous Message Pavel Stehule 2007-07-07 20:39:44 Re: Arrays of records?