On Wed, May 14, 2003 at 10:48:45AM -0400, Eric Sammer wrote:
> Not really a problem (yet), but out of curiousity...
> 
> I'm using Apache::DBI with postgres and while not serving requests, all 
> the postgres processes are listed as "idle in transaction." Obviously, 
> the DBI connect statements are configured with AutoCommit => 0. It 
> doesn't seem to cause any real problems, but it does concern me that 
> postgres considers itself in a transaction with only a connect (i.e. 
> prior to a $dbh->prepare()). I threw some SELECTs at it and it's fine, 
> but I worry about transaction blocking under heavier load and with 
> INSERT, DELETE, and UPDATE statements. ...or maybe I'm just thinking too 
> Oracle-ish about it.

I noticed an interesting problem with regards to dates and times.  If
you have columns that you let pgsql fill in, frex:

      Column      |        Type         |                   Modifiers
------------------+---------------------+-----------------------------------------------
 order_date       | date                | default date('now'::text)
 order_time       | time with time zone | default ('now'::text)::time(6) with time zone

Those dates and times will tend to be off, because pgsql uses the
exact date/time at the _start_ of the transaction.  And with Apache::DBI
the transaction could have been started quite some time ago, unless your
server is heavily loaded and/or you do lots of SELECT queries before
adding new rows (thus making sure you end up with a relatively fresh
transaction).

Just to illustrate this, I first get the current time on my server:

dev=> SELECT current_time;
       timetz
--------------------
 20:11:20.787832-04

Then I go to my mod_perl application and add a new account.  The
resulting row has:

 order_date |     order_time     
------------+--------------------
 2003-06-01 | 20:10:46.349862-04 

And order_time in this row is chronologically before, even though I
added the account _after_ typing 'SELECT current_time' in my psql
console...

The date can be off too, if Apache::DBI used an old, stale transaction
that started the previous day (this is very possible if a new record is
added alightly after midnight...)


Reply via email to