On Thu, 31 Dec 2009 12:35:49 -0500 Landreville landreville@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.