On Thu, 31 Dec 2009 12:35:49 -0500 Landreville <landrevi...@deadtreepages.com> wrote:
> I've just noticed the transaction_timestamp is actually way (up to > several minutes) before the database proc gets called. I'm on > postgresql 8.4 so the transaction_timestamp is when the transaction > started, and I compared it against the clock_timestamp (absolute > current time) and it is quite a bit off. > > Does adbapi start transactions before any method (ie runQuery) is > called? > > Or should I be looking at the underlying database driver to this > behaviour? I haven't looked at the code myself, but that seems a reasonable behaviour to me: - adbapi.ConnectionPool, as its name suggests, pre-allocates a bunch of database connections. - DBAPI2.0 requires that cursors default to doing things in a transaction. - PostgreSQL natively defaults to doing things immediately, outside a transaction, so running "BEGIN" on startup is a sensible thing for a PostgreSQL Python module to do. In fact, now that I think about it, I happen to know that PyPgSQL cursors (what RedHat packagaes as "postgresql-python") execute "BEGIN" on creation and immediately after each .rollback() or .commit(), and I suspect other libraries like psycopg2 would do much the same thing. _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
