Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)
От | Hannu Krosing |
---|---|
Тема | Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed) |
Дата | |
Msg-id | 36B1E9B3.B687BD5A@trust.ee обсуждение исходный текст |
Ответ на | Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed) (Patrick Verdon <patrick@kan.co.uk>) |
Список | pgsql-hackers |
Patrick Verdon wrote: > > > Even if there is a hard limit there is no way that > Postgres should die in this spectacular fashion. [snip] > I have reproduced this behaviour on both > FreeBSD 2.2.8 and Intel Solaris 2.6 using > version 6.4.x of PostgreSQL. > > I'll try to change some of the parameters > suggested and see how far I get but the bottom > line is Postgres shouldn't be dying like this. We definitely need a chapter on tuning postgres in some of the manuals. It should contain not only the parameters that one can change in PostgreSQL - for either better response or for taking a larger load - but also the ways one can tune the underlying OS, being it Linux, *BSD, Solaris or whatever. Even commercial databases (at least Oracle) tend to rebuild kernel during installation (obsereved with Oracle 7.1 on Solaris) When I once needed the info about setting shared memory limits on solaris I cried out here and got the example lines (I actually had them already copied from a macine where oracle was running) But the same info, and possibly more(increasing limits for max files per process/globally, shared mem config, ... whatever else is needed) seems to be essential part of setting up a serious DB server on any system. --------------- Hannu
В списке pgsql-hackers по дате отправления: