Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed) - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)
Date
Msg-id 36B1E9B3.B687BD5A@trust.ee
Whole thread Raw
In response to Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)  (Patrick Verdon <patrick@kan.co.uk>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Postgres Speed or lack thereof
Next
From: Tom Lane
Date:
Subject: Re: SELECT DISTINCT ON ... ORDER BY ...