rich.fromm wrote: > > 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 > > <...> > > 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? >
Did some more looking around on my own. Regarding (1), something similar seems to have been reported previously on the old mailing list: http://www.nabble.com/Segmentation-fault---mapserver---postgis-to12653945.html#a12674499 I think bug 2497 is at least partially addressing this: http://trac.osgeo.org/mapserver/ticket/2497 I can try locally applying the diff there, but I'm still a bit confused. Just moving the BEGIN and not inserting an END may solve a problem of unnecessary duplicate transactions, but I still don't understand how the transaction gets properly ended. Oh yeah, I do have for each LAYER: PROCESSING "CLOSE_CONNECTION=DEFER" I haven't found anything yet addresing (2). - Rich -- View this message in context: http://www.nabble.com/postgres-transaction-warnings-tp15749333p15749520.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
