X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id B79C752B0E for ; Thu, 21 Jul 2005 10:58:10 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 68932-03 for ; Thu, 21 Jul 2005 13:58:06 +0000 (GMT) Received: from smtp.iquer.net (smtp.iquer.net [195.234.230.108]) by svr1.postgresql.org (Postfix) with ESMTP id 8F50152ACD for ; Thu, 21 Jul 2005 10:58:05 -0300 (ADT) Received: from sponts0.iquer.net (sponts0.int.iquer.net [10.0.8.10]) by smtp.iquer.net (Postfix) with SMTP id BCC6A11E706 for ; Thu, 21 Jul 2005 15:58:05 +0200 (CEST) Received: from smtp.iquer.net (sv8.int.iquer.net [10.0.11.80]) by sponts0.iquer.net (SPONTS v2.1.80) with ESMTP id 10539AFC88D-0 for ; Thu, 21 Jul 2005 15:58:05 +0200 Received: from ws1.int.iquer.net (ws1.int.iquer.net [10.0.16.220]) by smtp.iquer.net (Postfix) with ESMTP id 95C4C10A71A for ; Thu, 21 Jul 2005 15:58:05 +0200 (CEST) From: Erik Wasser To: pgsql-sql@postgresql.org Subject: Are long term never commited SELECT statements are a problem? Date: Thu, 21 Jul 2005 15:57:56 +0200 User-Agent: KMail/1.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507211557.58822.erik.wasser@iquer.net> X-SPONTS-Version: 2.1.80 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200507/177 X-Sequence-Number: 22155 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