Re: COMMIT leads to ROLLBACK - Mailing list pgsql-hackers

From Gurjeet Singh
Subject Re: COMMIT leads to ROLLBACK
Date
Msg-id 65937bea0605211059s3f6705afs524c9d9c0c995f68@mail.gmail.com
Whole thread Raw
In response to Re: COMMIT leads to ROLLBACK  ("Jaime Casanova" <systemguards@gmail.com>)
List pgsql-hackers
refer: [HACKERS] Commit turns into rollback?
On 3/17/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> So it's not the fact that it rolls back that bugs you, it's the way that
> the action is reported?  We could talk about changing that maybe --- it
> wouldn't break existing scripts AFAICS.  It might break applications
> though.
  Yes, we should change the message. A silent SUCCESS message leads
the onlooker (script/application) to believe that everything was okay.
As Peter mentioned in the above-mentioned thread:

<snip>
The standard does address the issue of transactions that cannot be committed
because of an error.  In 16.6. <commit statement> GR 6 it basically says that
if the transaction cannot be completed (here: because of a constraint
violation), then an exception condition should be raised.  That is, the
transaction is over but you get an error.
</snip>
  As far as breaking-the-applications goes, I think we'll be
catching the broken applications rather than breaking any well wrtten
application (which detects a DML error as soon as it occurs, and
issues a rollback).

These are a few scenarios after entering an ABORTed transaction state:

1)
=# END;
ROLLBACK

2)
=# ROLLBACK;
ROLLBACK

3)
=# COMMIT;
ERROR: The transaction has been ended with a ROLLBACK.
  So, in effect, all these statements do end the ABORTed transaction
with a ROLLBACK. Whereas situations (1) and (2) behave just as
expected, situation (3) needs to be implemented with a
appropriate/correct error message.

Regards,
Gurjeet.

On 5/21/06, Jaime Casanova <systemguards@gmail.com> wrote:
> On 5/21/06, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
> > Hi All,
> >
> >    While trying to implement a recent TODO item, I noticed this behaviour:
> >
> > test=# select * from t2;
> > ERROR:  current transaction is aborted, commands ignored until end of
> > transaction block
> > test=# commit;
> > ROLLBACK
> >
> >    Either:
> >      1) COMMIT in an aborted transaction should lead to an 'ERROR:
> > Cannot COMMIT an aborted transaction.'
> >      2) At least a 'WARNING: transaction is being rolled back to last
> > known consistent state.' should precede the success (ROLLBACK)
> > message.
> >
> > Regards,
> > Gurjeet.
> >
>
> there was a thread about that two months ago...
>
> here's Tom's response:
> http://archives.postgresql.org/pgsql-hackers/2006-03/msg00786.php


pgsql-hackers by date:

Previous
From: "Jaime Casanova"
Date:
Subject: Re: COMMIT leads to ROLLBACK
Next
From: "Gurjeet Singh"
Date:
Subject: Re: COMMIT leads to ROLLBACK