Neil Conway wrote:
On Fri, 2004-11-19 at 16:17 +1300, Dru wrote:I'll get the developer to write down the exact error when it happens again.
Though one of hte developers
tells me that sometimes it gets a link resource allocation error on opening connections to the database server which i dont know if that is related.
I'm not sure what you mean by a "link resource allocation error". Can
you provide the exact error message you get when a connection is
refused? (Try checking the PostgreSQL logfile.)
I think he only gets it once or twice a week when using the database
server and grown accustomed to it. I myself when testing the database
server for errors dont get any at all when connections fail when they shouldnt fail :( .
I was using persistent connections initally and was getting this problemMax connections is set to 500, the webpage for the server code initalises and then closes the connection when its done.
It might be worth considering connection pooling or persistent
connections, although that shouldn't be related to the specific problem
you're having.
so switched to non-persistant and made sure i was cleaning them up afterwards
in case it helped solved this problem. I've replaced the db server and webserver
also to try and resolve it but that had no effect. I initally thought it might
be something to do with a kernel limit on sockets or something to that effect.
These connections are all TCP/IP based.
Does pg_dumpall or pg_dump lock the database block access to the database so you cant create connections?No.
Ok that rules out that possibility then.
Could it be possible postgresql can only create one connection at a time and if it gets two requests for a connection at the same time it fails?
No.
Ok rules out that possibility also. Is there any stress testing software for
postgresql to find out how and when it breaks? I wrote a simple script
to simulate 300 concurrent users on the webfrontend which breaks
the website real quick with 1 in 10 connections to db failing with no error
returned by connect just a dead connection. The website uses php,
the problem could be in the wrapper code for PHP though. I havnt
got much luck asking php developers about the problem though.
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
