From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hans-Jürgen Schönig <hs(at)cybertec(dot)at> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, shridhar_daithankar(at)persistent(dot)co(dot)in |
Subject: | Re: Pre-allocation of shared memory ... |
Date: | 2003-06-11 20:24:22 |
Message-ID: | 23593.1055363062@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <hs(at)cybertec(dot)at> writes:
> I have two explanations for the following behaviour:
> a. a bug
> b. not enough shared memory
> WARNING: Message from PostgreSQL backend:
> The Postmaster has informed me that some other backend
> died abnormally and possibly corrupted shared memory.
Is this a Linux machine? If so, the true explanation is probably (c):
the kernel is kill 9'ing randomly-chosen database processes whenever
it starts to feel low on memory. I would suggest checking the
postmaster log to determine the signal number the failed backends are
dying with. The client-side message does not give nearly enough info
to debug such problems.
There is also possibility (d): you have some bad RAM that is located in
an address range that doesn't get used until the machine is under full
load. But if the backends are dying with signal 9 then I'll take the
kernel-kill theory.
AFAIK the only good way around this problem is to use another OS with a
more rational design for handling low-memory situations. No other Unix
does anything remotely as brain-dead as what Linux does. Or bug your
favorite Linux kernel hacker to fix the kernel.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-06-11 20:28:50 | Re: Pre-allocation of shared memory ... |
Previous Message | Dann Corbit | 2003-06-11 20:05:26 | Re: Postgres performance comments from a MySQL user |