On 10/20/07, Rainer Bauer <usenet@xxxxxxxxxx> 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. ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
