Backends and semaphores

From: "Cary O'Brien" <cobrien(at)Radix(dot)Net>
To: pgsql-hackers(at)hub(dot)org
Subject: Backends and semaphores
Date: 1999-01-31 01:09:45
Message-ID: 199901310109.UAA26738@saltmine.radix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-01-31 01:24:49 Re: AW: [HACKERS] Another TEMP table trick
Previous Message Tom Lane 1999-01-31 00:42:25 Re: Reducing sema usage (was Postmaster dies with many child processes)