Re: Pre-allocation of shared memory ...
От | Bruce Momjian |
---|---|
Тема | Re: Pre-allocation of shared memory ... |
Дата | |
Msg-id | 200306112028.h5BKSoM16367@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Pre-allocation of shared memory ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Hans-Jürgen Schönig <hs@cybertec.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. Is there no sysctl way to disable such kills? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: