Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Patrick Verdon <patrick(at)kan(dot)co(dot)uk>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)
Date: 1999-01-30 08:05:50
Message-ID: Pine.BSF.4.05.9901300402480.3436-100000@thelab.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vadim Mikheev 1999-01-30 11:07:05 Re: [HACKERS] READ COMMITTED isolevel is implemented ...
Previous Message Michael Robinson 1999-01-30 08:04:18 Re: Visionary