On Wednesday 30 October 2002 20:09, Tom Lane wrote: > This strikes me as a fault on the client side, not in Postgres --- to > wit, poor connection management. It is not Postgres' job to kill idle > client connections.
I suppose you are right. The thing is we have never used persistant connections (tried to once, learned from the mistake..) and all the mod_php scripts (4.1.x version of PHP) do explicitly close their connections.. This might definitely be an apache problem of some kind. It seems to be less grave if I drop the MaxRequestsperChild config value for apache to an abysmal 100.. (Should _not_ be necessary, and is affecting our performance..) > But having said that, I do not think that idle connections per se would > cause any performance degradation on the server side. Perhaps they also > have open transactions that are holding locks that other queries need? > That again is really a client-side bug... Well, believe me, it does.. It only begins to be a real _problem_ not a symptom after 10 or so idle connections, but indeed postgresql drops in performance with too many open connections. I figured this part of the problem could possibly be lack of memory for the system, and I think I need to play with the postgresql.conf settings. I checked back in the archive for hints and tips, and found some, the box has 1GB of RAM, so I should be able to find some nice balance for it ! Regards -- Denis Braekhus - ABC Startsiden AS http://www.startsiden.no ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
