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...)