Skip site navigation (1) Skip section navigation (2)

Re: BUG #2115: If we CLOSE a Closed Cursor subsequent OPENs fail.

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: "David S(dot) Edwards" <dave(dot)edwards(at)bull(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #2115: If we CLOSE a Closed Cursor subsequent OPENs fail.
Date: 2005-12-15 03:22:53
Message-ID: 20051215032252.GA12655@winnie.fuhr.org (view raw or flat)
Thread:
Lists: pgsql-bugs
On Wed, Dec 14, 2005 at 06:16:19PM +0000, David S. Edwards wrote:
> We are evaluating Postgres for a very large customer who has a lot of legacy
> software that they have executed with several proprietary RDBMS. We have run
> into a situation that is common in their batch code. They OPEN a cursor
> (without WITH HOLD), FETCH rows, a COMMIT occurs, then sometime later they
> CLOSE then reOPEN the cursor. With Postgres, they are unable to reOPEN the
> cursor whereas with the other RDBMS they can.

The code you posted prints an error that tells what's wrong:

do OPEN
open sqlcode = -400
ERROR MESSAGE : 'current transaction is aborted, commands ignored until end of transa

The server log should show the complete error message:

ERROR:  current transaction is aborted, commands ignored until end of transaction block

After the COMMIT ECPG starts a new transaction, so when the subsequent
CLOSE fails the transaction is aborted and no further commands will
be allowed.  That's standard all-or-nothing transaction behavior:
everything succeeds or the transaction must be abandoned.  Apparently
the other database works differently than PostgreSQL and allows the
transaction to continue after certain types of error.

In PostgreSQL 8.0 and later you can defend transactions against
errors by using savepoints.  Declare a savepoint before code that
might fail, and if it does fail then rollback to the savepoint.  In
any case release the savepoint after the section of code that it
protects.

-- 
Michael Fuhr

In response to

pgsql-bugs by date

Next:From: Qingqing ZhouDate: 2005-12-15 04:14:49
Subject: Re: BUG #2113: PostgreSQL hangs after running for 2 days
Previous:From: Jon KeatingDate: 2005-12-15 02:27:49
Subject: BUG #2116: Searching text fields does not work in EUC_JP

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group