Re: [HACKERS] PostgreSQL and Solaris 7?

Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>>> Increasing # of semaphores should solve the problem, I guess. I'm
>>> going to try that as soon as I find the way to increase semaphores.

Right --- the messages Daryl is seeing indicate he's running out of
semaphores or semaphore IDs, not file space.  (Someone was too lazy
to create a separate kernel errno for out-of-semaphores.)

: IpcSemaphoreCreate: semget failed (No space left on device)                     ^^^^^^^^^^^^^

My guess is that the "WaitOnLock" and "stuck spinlock" complaints are
artifacts of not being able to recover from the out-of-semaphores
condition.  I hope to make this a little more robust in time for 6.5.

> I checked my Solaris box using sysdef and got:

>     10  entries in semaphore map (SEMMAP)
>     10  semaphore identifiers (SEMMNI)
>     60  semaphores in system (SEMMNS)
>     25  max semaphores per id (SEMMSL)

These settings are far too small if you hope to go beyond a couple dozen
Postgres backends.  Postgres requires one semaphore per backend, which
it (presently) allocates in groups of 16.  Thus you cannot get past 48
backends with these kernel settings --- starting the 49th backend requires
allocating semaphores 49-64, but your system is set up to allow only 60
semas total.

(If your platform doesn't have a TEST_AND_SET implementation then
several more semas are needed for spinlock emulation, but I assume
that's not a problem on Solaris.)

SEMMNI should also be bumped up, since you could not get past 10*16
backends with it set at 10 --- and that's not allowing for anything
else to be using semaphores!  It'd be foolish not to leave at least
a couple dozen semas and sema IDs free at Postgres' peak usage.

I dunno what SEMMAP is (no such parameter in my kernel) but it
probably needs to be at least as large as SEMMNI, possibly larger.

To run more than 64 backends you will also need to increase Postgres'
internal MaxBackendId constant.  Somewhere along here you are also
likely to run into other kernel configuration limits, like the total
number of processes, total processes for a single user, total number
of open files, etc.  These are all fixable but you don't want to
reboot the system to install new values very often.

We need a chapter in the installation guide that covers all this stuff
in more detail... offhand I don't even know how many open files to
allow per backend.
        regards, tom lane