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

From The Hermit Hacker
Subject Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)
Date
Msg-id Pine.BSF.4.05.9901300402480.3436-100000@thelab.hub.org
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
On Fri, 29 Jan 1999, Patrick Verdon wrote:

> 
> Tatsuo, Vadim, Oleg, Scrappy,
> 
> Many thanks for the response.
> 
> A couple of you weren't convinced that this
> is a Postgres problem so let me try to clear
> the water a little bit. Maybe the use of 
> Apache and mod_perl is confusing the issue -
> the point I was trying to make is that if 
> there are 49+ concurrent postgres processes
> on a normal machine (i.e. where kernel 
> parameters are the defaults, etc.) the 
> postmaster dies in a nasty way with 
> potentially damaging results. 
> 
> Here's a case without Apache/mod_perl that
> causes exactly the same behaviour. Simply
> enter the following 49 times:
> 
> kandinsky:patrick> psql template1 &
> 
> Note that I tried to automate this without
> success: 
> 
> perl -e 'for ( 1..49 ) { system("/usr/local/pgsql/bin/psql template1 &"); }'
> 
> The 49th attempt to initiate a connection 
> fails:
> 
> Connection to database 'template1' failed.
> pqReadData() -- backend closed the channel unexpectedly.
>         This probably means the backend terminated abnormally before or while processing the request.
> 
> and the error_log says:
> 
> InitPostgres
> IpcSemaphoreCreate: semget failed (No space left on device) key=5432017, num=16, permission=600


this error indicates taht you are out of semaphores...you have enough
configures to allow for 48 processes, but not the 49th...

> I have reproduced this behaviour on both 
> FreeBSD 2.2.8 and Intel Solaris 2.6 using
> version 6.4.x of PostgreSQL.

Both of them have "default" settings for semaphores...I don't recall what
they are, but the error you are seeing about IPCSemaphoreCreate indicates
that you are exceeding it...

> 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.

PostgreSQL cannot allocate past what the operating sytem has hardcoded as
the max...maybe a more graceful exit should be in order, though?  Or is
that what you mean?

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



pgsql-hackers by date:

Previous
From: Michael Robinson
Date:
Subject: Re: Visionary
Next
From: Michael Robinson
Date:
Subject: Re: Visionary