On Tue, Feb 12, 2002 at 10:00:03AM -0600, Philip Molter wrote: > On Tue, Feb 12, 2002 at 10:52:27AM -0500, Jeff Boes wrote: > : Does anyone here know if DBD::Pg starts a new transaction after a > : COMMIT? That is, it appears that... > : > : > : $dbh->do(...); > : $dbh->commit(...); # End of one transaction > : > : # Code here will have an implicit 'BEGIN' > : > : If this is the case, it would explain some performance problems we are > : having. We have some detached processes running as daemons with open > : database handles. We get a lot of these messages: > : > : NOTICE: InvalidateSharedInvalid: cache state reset > : > : which I'm told implies that we have a lot of "idle in transaction" > : processes. > : > : If all this is true, how do I fix it? Must my idle daemons release > : their database handles? What about mod_perl processes? > > >From the DBD::Pg man page: > > If AutoCommit is switched-off, immediately a transaction will be > started by issuing a 'begin' statement. Any 'commit' or 'rollback' > will start a new transaction. A disconnect will issue a 'rollback' > statement. > > That would imply 'yes'. I think that's actually a feature of the > DBI, not just DBD::Pg, because the same holds true for other DBDs.
A feature of the DBI _specification_. I should probably change it to use words that make it clear that the driver is free to not start a new transaction until the application does any DDL or DML statements. > Use begin_work() or set AutoCommit=1 on your handles and then turn > AutoCommit off for your transactions. Yeap. Tim.
