I said: > Hm. The parallel regression tests require at least 20. I deliberately > allowed initdb to select values as small as 10 on the theory that > installing and not being able to run the parallel regression tests is > better than not installing at all.
Actually, after trying to reproduce the problem on my own OS X machine, I realize that it's a little more subtle than I thought. The Darwin port does not use SysV semaphores at all (it uses Posix semaphores) and so the resource restriction you're hitting must actually be the max-shared-memory limit, rather than number-of-semaphores as I first assumed. max_connections does have an impact on shared memory size, though not as large as shared_buffers has. Therefore, the real problem is that initdb initially probes for a workable number of shared_buffers while using max_connections=5, and then it selects max_connections while holding shared_buffers constant. I was thinking that a small max_connections would prevent us from mistakenly choosing tiny shared_buffers when the system's real restriction is on number of semaphores. But what we seem to have here is that the selected number of buffers was just a little under the system's max-shared-memory limit, so that max_connections could be raised to 10 but not to 20. (BTW, on my OS X machine, with out-of-the-box configuration, initdb selects shared_buffers 400 and max_connections 20. I'm guessing that you had either a nondefault shared memory limit, or some other process using shared memory.) Perhaps we should avoid all attempts at cuteness and just run the initial probes for workable shared_buffers with max_connections=20, as well as making that be the minimum max_connections value probed for. Anyone see a better way? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]