Backends and semaphores - Mailing list pgsql-hackers

From Cary O'Brien
Subject Backends and semaphores
Date
Msg-id 199901310109.UAA26738@saltmine.radix.net
Whole thread Raw
List pgsql-hackers
I agree with tom lane that a simple approach to running
out of semaphores is sufficient.

I've run into problems on systems where several systems (Oracle,
Tuxedo, and (i think) something else) all used semaphores.  We got
into some wierd situations where as the load built up, the system
would run out of semaphores.  But depending on how things ramped up,
sometimes Oracle would run out, sometimes Tuxedo.  (Ok, I've got to
put in a disclamer.  I *THINK* this is what was going on in this
system.  Actually I think it was running out of undo buffers.  Same
thing.).

The point?  IMHO, the safest thing is to have a configurable (command
line ?)  max backends.  When postmaster starts, it allocates the
necessary number of semaphores for the max number of backends.  Backend
forks beyond this number simply don't happen.

If the system doesn't have enough, we know right away.  If PostgreSQL
starts, snarfs up a bunch of semaphores, and then some OTHER system
runs out of semaphors, then ipcs will pretty quickly show what is
going on.  Better this than an indeterminate failure based on which
software package gets more load first.

Just one man's opinion.  

-- cary




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Reducing sema usage (was Postmaster dies with many child processes)
Next
From: Bruce Momjian
Date:
Subject: Re: AW: [HACKERS] Another TEMP table trick