Are long term never commited SELECT statements are a problem?

Hello List,

I've written an application in perl using DBI with MySQL (no transaction
support). Then we decide to migrate it to postgresql
(postgresql-8.0.1-r4).

At first we were using 'AutoCommit => 1' with the application. That
means that every statement will be commited right away.

Then I discovered the 'magic of transactions' and set AutoCommit to 0.
Then I rewrite many UPDATE and INSERT statements with support for
commit and rollback. BUT: the SELECT statements were untouched (and
that was mistake I think).

Now I've got here a blocking problem. Severel SQL statements (like
renaming a field or UPDATE of a field) are blocked until I kill a
certain task. This task DOES only the INSERTS and UPDATES with a
transaction and the SELECT statements are not within an transaction.
And this task is a long term running task (some kind of daemon) so the
SELECT transactions will never be commited. Are long term never
commited SELECT statements are a problem and could that lead to
blocking other queries?

To put it in annother way: what kind of thing I produced with the
following pseudocode?

# open database
$DBH = DBI->connect(...,USERNAME,PASSWORD, { RaiseError => 1, AutoCommit
=> 0 });

while (true)
{
# do some select
SELECT ... FROM ...
# do some more
SELECT ... FROM ...

if (condition)
# do an UPDATE/INSERT
eval {
UPDATE/INSERT/...
$DBH->commit;
};
if ($@) {
warn "Transaction aborted: $@";
eval { $DBH->rollback };
}
}
}

Is this some kind of nested transaction? Can there be a problem with
this code?

Thanks for your help!

--
So long... Fuzz