max_connections/shared_buffers (was Re: Beta4 Tag'd and Bundled ...)

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