I'm doing stress tests on a system with a java webapp running under tomcat, using java mapscript and mapserver 5.0.0 (hand patched to fix mapserver bug 2525 (http://trac.osgeo.org/mapserver/ticket/2525)), fetching data from a postgresql 8.1 / postgis 1.1.2 server. In my postgres log file (/var/log/postgresql/postgresql-8.1-main.log), I see a TON of messages like the following:
2008-02-28 13:48:08 PST WARNING: there is already a transaction in progress The default value in the postgres configuration (/etc/postgresql/8.1/main/postgresql.conf) for max_prepared_transactions is only 5. Based on the documentation here: http://www.postgresql.org/docs/8.1/interactive/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY I increased it substantially, so that it has the same value as max_connections: http://www.postgresql.org/docs/8.1/interactive/runtime-config-connection.html#GUC-MAX-CONNECTIONS So now I would think that each connection to the database could simultaneously perform a transaction if so desired. But I still get a TON of such messages, with no noticeable reduction. This brings up a few questions: 1) In the mappostgis.c source, I see a number instances of transactions starting, via "BEGIN" statements. There are also a number instances of transactions being canceled, via "ROLLBACK" statements, when something goes wrong. However, I can not find a single instance of a transaction being normally closed, via an "END" statement. Is the code perhaps somehow leaking transaction resources? Or maybe there's a genuine reason that "END" statements aren't needed? Maybe something in some of the PQfoo() methods indirectly accounts for this? I haven't looked at it in much detail, but I don't see anything in the libpq docs (http://www.postgresql.org/docs/8.1/static/libpq-exec.html) that suggests this. 2) In my situation, the database is effectively read only, because updates will happen infrequently and always in bulk and offline. So I would think that transactions are totally unnecessary, since any individual read statement will by definition see a consistent view of the database. Transactions aren't going to help at all, and would I think only serve to consume resources and possibly adversely affect performance. I can see how they might be needed in cases where updates were expected, but in my case I would like to be able to disable them. Is there any option to do this? I assume no. But even if that is the case, is this analysis correct, and might such an option be a useful feature to provide? So far this situation does not seem to be affecting correctness, and performance is not unreasonable, but I wonder if performance might be better if I could do something such that these WARNINGs were not present. Thanks for any help that anyone might be able to provide. - Rich -- View this message in context: http://www.nabble.com/postgres-transaction-warnings-tp15749333p15749333.html Sent from the Mapserver - User mailing list archive at Nabble.com. _______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
