I ran into something like this once, where a complex update occurred inside a transaction. When the update happened, I saw what you describe - the DB hung, and the load average shot out thru the roof until I restarted the PG daemon. The query otherwise worked fine, but only failed with this specific set of input data, about which nothing was unusual. (and now long since gone) I never found out exactly what it was that caused the problem, but rewording the query to something functionally identical but differently structured solved it. I've never seen the problem since. Wish I had more to say that might help identify the actual problem. I'm using Postgres 7.3.9 on Fedora Core 1. -Ben On Tuesday 25 October 2005 13:33, Oliver Elphick wrote: > On Tue, 2005-10-25 at 13:14 -0700, Kishore B wrote: > > Hi , > > I am Kishore doing freelance development of J2EE applications. > > > > > > We switched to use Postgresql recently because of the advantages it > > has over other commercial databases. All went well untill recently, > > untill we began working on an application that needs to maintain a > > huge database > > > > > > > > We are executing a single query that returned very fast on the first > > instance. But when I executed the same query for multiple times, it is > > giving strange results. It is not coming back. > > > > When I checked with the processes running in the system, I observed > > that multiple instances of postmaster are running and all of them are > > consuming very high amounts of memory. I could also observe that they > > are sharing the memory in a uniform distribution across them. > > > > Can you please let me know if you have experienced the same and how do > > you resolved it. > > > > Thank you, > > Kishore. > > No, I haven't seen anything like that. > > I am forwarding this mail to the general enquiries list, in case anyone > else can help. > > -- > Oliver Elphick olly@xxxxxxxxxx > Isle of Wight http://www.lfix.co.uk/oliver > GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA > ======================================== > Do you want to know God? http://www.lfix.co.uk/knowing_god.html > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
