On 10/20/07, Rainer Bauer <usenet@munnin.com> wrote:
> Anyway, the problem are the no. of semaphores created by Postgres:
> Every backend creates at least 4*<max_connections> semaphores. Just
> increase <max_connections> to an unusual high value (say 10000) and
> start creating new connections while monitoring the handle count.
Hmm, they're actually the same semaphores, so the only cost is for
slots in each process's handle table, which comes from kernel paged
pool. Testing shows I can easily create about 30 million handles to a
given object on this machine. This is under win2003 with 1.25GB RAM,
which gives it a paged pool limit of 352MB.
I tried going up to 20000 max_connections, and still blew postmaster's
VM space long before paged pool was exhausted. I couldn't test any
higher values, as there's some interaction between max_connections and
shared_buffers that prevents it from mapping the buffer contiguously.
Something's missing though, since I'm not hitting the same issue you
are. How are you generating the connections? I just have an app
calling PQconnectdb() in a loop, but I guess that's not good enough.