Thread: Implicit Transactions

Implicit Transactions

From
Chip Gobs
Date:
We are porting from Informix to  PostgreSQL 7.4.5 and have noticed the
following behavior.

If we try to OPEN a CURSOR  for an invalid SELECT statement in ECPG, we
get an error, as expected.  However, if we then
attempt to OPEN another CURSOR  for a valid statement, we get an error
that says we are in a failed transaction.   At that point, no statement
will succeed.   The only way we have found to get out of this state is
to ROLLBACK explicitly.

We are not using explicit transactions.  My understanding is that PG
should be rolling back failed statements when we are not in an
explicit transaction.

Do we have an incorrect setting, a misunderstanding of how it is
supposed to work, or a bug? Could anyone enlighten me?

Thanks,

Chip



Re: Implicit Transactions

From
Bruce Momjian
Date:
Chip Gobs wrote:
> 
> We are porting from Informix to  PostgreSQL 7.4.5 and have noticed the
> following behavior.
> 
> If we try to OPEN a CURSOR  for an invalid SELECT statement in ECPG, we
> get an error, as expected.  However, if we then
> attempt to OPEN another CURSOR  for a valid statement, we get an error
> that says we are in a failed transaction.   At that point, no statement
> will succeed.   The only way we have found to get out of this state is
> to ROLLBACK explicitly.
> 
> We are not using explicit transactions.  My understanding is that PG
> should be rolling back failed statements when we are not in an
> explicit transaction.
> 
> Do we have an incorrect setting, a misunderstanding of how it is
> supposed to work, or a bug? Could anyone enlighten me?

ecpg defaults to open transaction by default.  There is a command to
change that in ecpg or during compile I think.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073