X-Original-To: pgsql-sql@postgresql.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 0EA18475F2C for ; Mon, 7 Apr 2003 04:39:02 -0400 (EDT) Received: from ns3.biznetindia.com (unknown [203.200.89.83]) by postgresql.org (Postfix) with ESMTP id 1AB28475F0D for ; Mon, 7 Apr 2003 04:39:00 -0400 (EDT) Received: from mail.linux-delhi.org ([203.145.144.116]) by ns3.biznetindia.com (8.12.8/8.12.5) with ESMTP id h378ch7j004631 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 7 Apr 2003 14:08:56 +0530 Received: from mail.linux-delhi.org (localhost [127.0.0.1]) by mail.linux-delhi.org (8.12.8/8.12.5) with ESMTP id h378cErT015914 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 7 Apr 2003 14:08:14 +0530 Received: (from raju@localhost) by mail.linux-delhi.org (8.12.8/8.12.8/Submit) id h378cDTJ015910; Mon, 7 Apr 2003 14:08:13 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16017.14581.156730.440857@mail.linux-delhi.org> Date: Mon, 7 Apr 2003 14:08:13 +0530 To: pgsql-sql@postgresql.org Subject: Re: DBD::Pg transaction issues In-Reply-To: <200304071245.28635.mallah@trade-india.com> References: <16016.65329.971768.399349@mail.linux-delhi.org> <200304071245.28635.mallah@trade-india.com> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid From: Raj Mathur X-Spam-Status: No, hits=-24.4 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_SBL,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200304/89 X-Sequence-Number: 12790 Hi Rajesh, >>>>> "Rajesh" == Rajesh Kumar Mallah writes: Rajesh> Dear Raju, Rajesh> All subsequest statements (DML/DDL/SELECT) are ignored Rajesh> after the first ERROR caused by any statement in the Rajesh> transaction. the current transaction must be rollbacked Rajesh> and new one started. Rajesh> I can think of two approaches: Rajesh> a) Prevent the error situation from arising may be by Rajesh> first querying if the reference exists. Which is what I'm doing now; it's an inelegant and inefficient solution. Rajesh> b) commit when the operation succeds and rollback when Rajesh> there is ERROR from sql. That's not an alternative, since I need to commit either all the record in the file or none of them. Rajesh> In perl-DBI eval is gnerally used for catching such SQLs Rajesh> without aborting the program. Am using eval's, but the transaction gets aborted in any case. The eval is only useful for my program to trap the error. I'm trying to find out how I can prevent the transaction mechanism from treating errors on the database as logical errors. So is there no way to prevent PostgreSQL (or DBI) from aborting the current transaction if an operation on the database fails? Regards, -- Raju Rajesh> while (true ) { Rajesh> eval { }; if ($@) { $dbh -> Rajesh> commit(); } else { $dbh -> rollback(); } } Rajesh> in both cases you loose on performance in forfer case to Rajesh> to checking overhead and in laters repeated comitting. Rajesh> regds mallah. Rajesh> On Monday 07 Apr 2003 10:01 am, Raj Mathur wrote: >> Hi, >> >> Am using DBD::Pg with PostgreSQL 7.2.3, Perl 5.8.0. I have a >> set of updates to a table which has (a) references to another >> table and (b) possibly duplicates. >> >> The data is in a text file, which is read record by record and >> appended to the database table. A transactions spans the >> complete reading of the text file. >> >> If the cross-reference field in the file doesn't exist in the >> referenced table I want to ignore the record. >> >> If the record already exists in the table I want to perform >> some updates to the existing data. >> >> The problem is that the first record in the text file that has >> an invalid reference, or one that already exists, causes the >> transaction to abort and all subsequent updates from the file >> to fail. Is there any way to tell DBI/PostgreSQL that it >> should continue the transaction until the program directs it to >> commit/rollback? >> >> Tried the following so far: >> >> Set RaiseError to null. No effect. >> >> Currently manually checking for duplicates/missing referenced >> records and taking appropriate action when found. Pretty >> inelegant. >> >> Pseudocode: >> >> open text file begin transaction while read text record write >> into table if write failed due to duplicate read existing >> record update values in existing record rewrite record else if >> write failed due to missing reference ignore record else mark >> file as bad >> >> if file not bad commit else rollback >> >> Hope this is the right list to be asking on. >> >> Regards, >> >> -- Raju -- Raj Mathur raju@kandalaya.org http://kandalaya.org/ It is the mind that moves