> Hello, > Yes, tried that, but did not solve it. Only the cited approach did it. > We even tried the same idea: explicitly locking the entire table during > inserts, > updates, deletes. The results were as expected at performance (VERY poor as > pgpool "serialized" all these previously simultaneus transactions), and an > unexpected side effect (with our confs): RAM usage "exploded" during stress > test > and we had to hard reboot the machine. > The kind of transaction row locking was the less penalty we found. > > We are still stress loading the pool and it did not have a single failure > since > then. > It worked for our php app, but it should be tested for other apps. > How about binary only unmodifiable apps?
Ok, so your application issues not only INSERT but other DMLS. Or worse, DMSs use values from prevous SELECT. Anyway, problem is I don't know what are your SQLs which cause your problem. If you could show us a self contained test case, I may be able to think of better way... -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
