Re: [Fwd: Re: BUG #2168: 45.000.000 records too much?]

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steven Mooij <steven(at)mooij(dot)name>
Cc: Rudolph Froger <r(dot)froger(at)estrate(dot)nl>, pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: [Fwd: Re: BUG #2168: 45.000.000 records too much?]
Date: 2006-01-18 16:19:31
Message-ID: 10547.1137601171@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Steven Mooij <steven(at)mooij(dot)name> writes:
> LOG: background writer process (PID 8208) was terminated by signal 9
> LOG: terminating any other active server processes
> LOG: statistics collector process (PID 8209) was terminated by signal 9

Kill -9 is not something Postgres ever initiates; where it is probably
coming from is the Linux kernel's emergency out-of-memory handling code.
You really ought to disable OOM kills because they are utterly unsafe :-(
In the above example the kernel has chosen to kill innocent bystander
processes instead of the process that was actually sucking the memory.
See "Linux Memory Overcommit" at
http://www.postgresql.org/docs/8.1/static/kernel-resources.html#AEN18105

As for where the memory is being sucked, it's the list of pending
foreign-key checks during your insert into t_test2. If you can't
increase the amount of memory available, you'll need to break the
insertion into smaller chunks. Or perhaps not add the foreign key
constraint till after the table is built. (Eventually we need to
improve PG so that it can cope with enormous pending-foreign-key lists,
but that's not been done yet.)

regards, tom lane

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2006-01-18 16:34:19 Re: Huge number of disk writes after migration to 8.1
Previous Message Gilles 2006-01-18 15:38:17 BUG #2180: log_statement=mod does not work