cannot detect too many clients

From that error below it looks to me that you will need to recompile your

kernel (or whatever) to add support for more shared memory and more shared
semaphores.

Try this URL:

http://www.ca.postgresql.org/devel-corner/docs/admin/kernel-resources.html

Chris

From that error below it looks to me that you will need to recompile your

kernel (or whatever) to add support for more shared memory and more shared
semaphores.

My point is 7.1 or earlier behaves different from current. 7.1 or
earlier's postmaster won't start if there is not enough shared memory
and semaphores.

I just want to know if that's a intended behavior.
--
Tatsuo Ishii

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

I have a fatal error message while connecting more than 32 users using
current:

Aug 29 11:25:18 srapc1474 postgres[12189]: [1] FATAL 1:
ProcGetNewSemIdAndNum: cannot allocate a free semaphore

rather than a more informative message:

Sorry, too many clients already

Does anynbody know what's happening?

Ugh. I thought I'd tested that. The problem is that it runs out of
semaphores before noting that there's no free slots in the PROC array
(which is where the "more informative" message was supposed to come
out). Need to rearrange the order of operations, or some such.
Will fix.

regards, tom lane

I wrote:

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

I have a fatal error message while connecting more than 32 users using
current:
Aug 29 11:25:18 srapc1474 postgres[12189]: [1] FATAL 1:
ProcGetNewSemIdAndNum: cannot allocate a free semaphore
rather than a more informative message:
Sorry, too many clients already
Does anynbody know what's happening?

Ugh. I thought I'd tested that.

Indeed I had, but I'd used a low value of MaxBackends to test it.
If MaxBackends is a multiple of PROC_NSEMS_PER_SET (16) then too-many-
backends will be detected here, not later on when we try to insert our
PROC entry into the sinval array. Whoops. Fix committed.

regards, tom lane