X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id EF2D2D1B4FD for ; Sun, 9 Nov 2003 22:09:40 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 59042-08 for ; Sun, 9 Nov 2003 18:09:12 -0400 (AST) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id 472E1D1B515 for ; Sun, 9 Nov 2003 18:09:10 -0400 (AST) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 2D06035293; Sun, 9 Nov 2003 14:09:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 2B8FE35286; Sun, 9 Nov 2003 14:09:12 -0800 (PST) Date: Sun, 9 Nov 2003 14:09:12 -0800 (PST) From: Stephan Szabo To: holger@jakobs.com Cc: pgsql-sql@postgresql.org Subject: Re: transaction processing after error in statement In-Reply-To: <20031107221659.55CBC3CA93@smtp1.netcologne.de> Message-ID: <20031109140156.T85218@megazone.bigpanda.com> References: <20031107221659.55CBC3CA93@smtp1.netcologne.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200311/77 X-Sequence-Number: 15892 On Fri, 7 Nov 2003 holger@jakobs.com wrote: > Whenever an error occurs within the transaction, PostgreSQL puts the > whole transaction in an *ABORT* state, so that there is no difference at > all between COMMITing or ROLLBACKing it. Even commands successfully > carried out before the error ocurred are rolled back, even if I COMMIT > the transaction, where no error message whatsoever is shown. In PostgreSQL all errors are currently considered unrecoverable, and all statements in a transaction must commit or rollback together as a single unit. In the future an implementation of nested transactions or savepoints would presumably relax this limitation to only the successfully committed subtransactions or statements that were not separately rolled back to a previous savepoint. > Additionally, I have discovered that phantom reads occur in PostgreSQL > even if isolation mode serializable is used. Also not so nice! You're going to have to give more information for anyone to even begin to understand the case you're seeing.