Venki, Postgres is using a thread per _realized_ connection, and reserves some memory per _configured_ connection. So setting the configured connection count too high is not free even if normally you won't have that many connections actually open. And of course at peak load the number of connections will go high, causing higher resource usage, which might be worse than handling the same load with a fixed number of connection managed by a connection pool. So the short answer to your question is: you should look into using a connection pooling solution for accessing the DB. I guess you're using .net, which I have absolutely no idea about, but I guess there must be some connection pooling project, general or postgres specific - search for it :-) HTH, Csaba. On Mon, 2005-10-10 at 17:59, Venki@xxxxxxxxxx wrote: > > > Hi All, > I am sorry if this was already discussed. I am new to the world of > postgressql and was experincing a problem for which I need help of an > expert in this lists. > We have devloped a site(asp.net 1.1) for which we have used postgresql 7.4 > as the backend database. When the number of connections increases we are > getting an error "Too many clients are connected" we then adjusted the > number of connections from the initial value of 30+ to 200 it get solved > initially but we are experincing the same problem again. Before adjust the > connection settings I would like some one with answers to the following > questions. > 1. How does postgresql handles database connections? > 2. Under what situations does this error "Too many clients connected" is > thrown? > 3. Should we increase the max connection settings to say 1000 if yes what > about the PC configuration that is needed for it. We are currently running > the postgresql in a linux box with 1 GB ram and 2GHZ xeon processor. > 4. is it advisable to upgrade postgresql to 8.0?? will it solve this error > once and for all. > > Thanks in advance > > regards > venki > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
